Czy można połączyć historie dwóch plików w git?
Chodzi o to, ze zmieniłem nazwę pliku i katalogu i git uwaza, ze plik zostal usuniety, a nowy plik dodany, a chce miec ciaglosc.
0
4
Wbrew pozorom Git wcale nie śledzi diffów, a całe drzewa - stąd zależnie od wybranego przez Ciebie algorytmu porównywania (wykorzystywanego przy git show etc.) patrząc na ten sam commit raz możesz otrzymać informację elo plik został przeniesiony, a raz elo plik został usunięty i utworzony na nowo.
tl;dr zmień algorytm diffowania (git config --global diff.algorithm)
Ewentualnie możesz pokombinować z git mv, ale wydaje mi się, że to algorytm diffowania będzie tutaj kluczem.
4
git nie śledzi zmian, a robi snapshoty. każdy commit to oddzielny snapshot całego repozytorium. całość jest pod spodem optymalizowana pod względem zajętości dysku (deduplikacja i kompresja), więc patrząc na rozmiar metadanych gita wygląda to z pozoru jakby same diffy były zapisywane.
git wykrywa zmiany w plikach robiąc diffa między dwoma snapshotami. pliki o identycznej zawartości pod identycznymi ścieżkami można od razu pominąć. resztę trzeba porównać, policzyć jakoś podobieństwo. według https://dev.to/jennieji/how-to-read-a-raw-git-diff-1pl2
Git judge the similarity of 2 files via a percentage number called similarity index, which represents the unchanged lines percentage of the file.
If similarity index is larger than 50%, git think you renamed the file, and did some small changes. And the changs of both files would be combined in one diff block. 50% could be configured according to git document here.
teoretycznie może być nawet tak, że usuniesz plik, dodasz inny, ale o bardzo podobnej zawartości i git pomyśli, że tylko zedytowałeś i zmieniłeś położenie starego pliku
Paweleczek napisał(a):
Czy można połączyć historie dwóch plików w git?
Chodzi o to, ze zmieniłem nazwę pliku i katalogu i git uwaza, ze plik zostal usuniety, a nowy plik dodany, a chce miec ciaglosc.
prawdopodobnie zrobiłeś zarówno dużo zmian w zawartości pliku jak i zmieniłeś jego położenie jednocześnie. w ogólności, najskuteczniejszym sposobem sprawienia by git dobrze wyśledził historię pliku jest rozbicie tych zmian na dwa kroki:
- jeden krok to względnie duża zmiana zawartości pliku bez zmiany jego położenia
- drugi krok to względnie mała zmiana zawartości pliku wraz ze zmianą jego położenia
0
Ustawilem algorytm histogram , ale to nic nie dalo. Czy to moze miec cos wspolnego z tym, ze w miedzyczasie dodalem kilka commitow?
2
Paweleczek napisał(a):
Ustawilem algorytm histogram , ale to nic nie dalo. Czy to moze miec cos wspolnego z tym, ze w miedzyczasie dodalem kilka commitow?
w sensie zakładasz, że wybór algorytmu diffowania jest zapisywany w historii gita? nie jest. tak jak napisałem, git zapisuje całe snapshoty, a nie diffy. dopiero jak chcesz zobaczyć diffa to git go od nowa oblicza, wykorzystując taki algorytm jaki mu w danej chwili ustawiłeś.
u mnie osobiście sprawdza się podejście, o którym napisałem wyżej, tzn:
Wibowit napisał(a):
prawdopodobnie zrobiłeś zarówno dużo zmian w zawartości pliku jak i zmieniłeś jego położenie jednocześnie. w ogólności, najskuteczniejszym sposobem sprawienia by git dobrze wyśledził historię pliku jest rozbicie tych zmian na dwa kroki:
- jeden krok to względnie duża zmiana zawartości pliku bez zmiany jego położenia
- drugi krok to względnie mała zmiana zawartości pliku wraz ze zmianą jego położenia
jak do tej pory, dzięki temu podejściu, git zawsze wyłapuje moje zmiany w pliku oraz zmianę jego nazwy. są od tego oczywiście wyjątki, jak np. pocięcie pliku na kilka kawałków, poprzenoszenie dużych części kodu między plikami, etc ale tutaj ograniczeniem jest sam format diffa, który zakłada tylko zmiany w obrębie jednego pliku (i to tylko linowe).
żeby odzyskać historię pliku będziesz musiał, oprócz powyższego rozbicia zmiany na dwa kroki, także przepisać istniejącą historię commitów, a więc podszkolić się w rebase'ach i na końcu machnąć push --force, którym popsujesz życie innym, którzy już mają kopię twojego repozytorium. jeśli inni już zaciągnęli już tego felernego commita i nad nim zrobili wiele swoich zmian to już raczej za późno żeby naprawiać historię.
0
Wibowit napisał(a):
żeby odzyskać historię pliku będziesz musiał, oprócz powyższego rozbicia zmiany na dwa kroki, także przepisać istniejącą historię commitów, a więc podszkolić się w rebase'ach i na końcu machnąć push --force, którym popsujesz życie innym, którzy już mają kopię twojego repozytorium. jeśli inni już zaciągnęli już tego felernego commita i nad nim zrobili wiele swoich zmian to już raczej za późno żeby naprawiać historię.
Czyli co, musialbym usunac commity po tym felernym commicie i potem szukac, ktore zmiany byly dodane do poszczegolnych commitow, zeby je odtworzyc?
Myslalem, ze da sie zaznaczyc dwa pliki i kazac mu polaczyc commity z tych plikow w jeden, ale widze, ze to wieksza zabawa.
Co do utrudniania zycia innym, to nie ma obaw, bo to moj prywatny projekcik.
1
Myslalem, ze da sie zaznaczyc dwa pliki i kazac mu polaczyc commity z tych plikow w jeden, ale widze, ze to wieksza zabawa.
jak już napisałem, git nie zapisuje i nie wie co się stało między commitami, a zamiast tego próbuje to wydedukować z różnic między commitami (czyli snapshotami). im więcej rzeczy się działo między dwoma snapshotami, tym trudniej jest gitowi wydedukować (poprawnie zgadnąć) co się dokładnie stało. dlatego przy pracy z gitem lepiej mieć mniejsze commity niż większe (w sensie zmiany rozbijać na więcej commitów niż mniej).
Czyli co, musialbym usunac commity po tym felernym commicie i potem szukac, ktore zmiany byly dodane do poszczegolnych commitow, zeby je odtworzyc?
musiałbyś się cofnąć do momentu sprzed felernego commita, potem dodać dwa nowe commity (powstałe z rozbicia tego felernego commita i je już opisałem w poprzednich postach), następnie zrebase'ować wszystkie pozostałe commity (czyli pominąć ten felerny), a wtedy jak już będziesz miał lokalnie dobrą historię commitów to możesz zrobić git push --force.
nieco bardziej obrazowo:
teraz masz taką historię commitów (od najnowszego do najstarszego commita):
zmiana e <- origin/master + lokalny master
zmiana d
zmiana c = edycja i zmiana nazwy pliku <- felerny commit
zmiana b
zmiana a
cofasz się do commita sprzed tego felernego:
zmiana e <- origin/master
zmiana d
zmiana c = edycja i zmiana nazwy pliku <- felerny commit
zmiana b <- lokalny master
zmiana a
następnie dodajesz dwa nowe commity powstałe z rozbicia tego felernego (zmiana c) - pokazuję tylko brancha lokalny master:
zmiana c2 - edycja pliku <- lokalny master
zmiana c1 - zmiana nazwy pliku
zmiana b
zmiana a
następnie rebase'ujesz pozostałe commity (czyli zmiana d i zmiana e) z origin/master na lokalnego mastera (commity po rebasie oznaczę apostrofem):
zmiana e' <- lokalny master
zmiana d'
zmiana c2 - edycja pliku
zmiana c1 - zmiana nazwy pliku
zmiana b
zmiana a
teraz porównujesz lokalnego mastera z origin/master i jeśli są identyczne (tzn. wszystko poszło jak trzeba) to robisz git push --force i zostajesz z czymś takim (teraz znowu pokazuję oba branche):
zmiana e' <- origin/master + lokalny master
zmiana d'
zmiana c2 - edycja pliku
zmiana c1 - zmiana nazwy pliku
zmiana b
zmiana a