Dlaczego git log nie pokazuje historii przeniesionego pliku i co mogę z tym zrobić?

Question

Zmieniono nazwę kilku plików za pomocą git mv, użyłem git stash, rzuciłem okiem na HEAD (bez zmiany), a następnie git stash pop, aby odzyskać całą partię. Moje ruchy zniknęły z listy commitów, więc zmieniłem je na git rm, a wiadomość zatwierdzenia, o której twierdziło git, zauważyła zmianę nazwy. Więc nie myślałem o tym więcej.

Ale teraz, po zatwierdzeniu, nie mogę uzyskać historii przeniesionych plików! Oto co mówi na temat git commit w pytaniu:

~/projects% git log --summary 
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a 
Author: brone 
Date: Wed Dec 8 22:37:54 2010 +0000 

    Moved R_DebugUI into runtime 

delete mode 100644 test/R_DebugUI_iOS.h 
delete mode 100644 test/R_DebugUI_iOS.m 
create mode 100644 system/runtime/src/R_DebugUI_iOS.h 
create mode 100644 system/runtime/src/R_DebugUI_iOS.m 

<<snip older commits>> 
~/projects% 

Jestem teraz próbuje historię jednego z tych plików przeniesione, więc mogę patrzeć na starej wersji, ale nie dostaniesz nic bardzo przydatne:

~/projects/system/runtime/src% git log --follow --find-copies-harder -M -C R_DebugUI_iOS.m 
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a 
Author: brone 
Date: Wed Dec 8 22:37:54 2010 +0000 

    Moved R_DebugUI into runtime 
~/projects/system/runtime/src% 

(ja również próbowałem go bez -M, -C i --find-copies-harder, ale bezskutecznie.)

mogę dostać swoją historię pod swoją starą nazwą, który zatrzymuje się w punkcie, to było usunięto ze starej lokalizacji:

~/projects% git log --summary --follow --find-copies-harder -M -C -- test/R_DebugUI_iOS.m 
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a 
Author: brone 
Date: Wed Dec 8 22:37:54 2010 +0000 

    Moved R_DebugUI into runtime 

delete mode 100644 test/R_DebugUI_iOS.m 

commit 32a22d53c27e260714f759ecb3d3864e38b2e87f 
Author: brone 
Date: Tue Dec 7 23:52:51 2010 +0000 

    Can set debug UI's alpha. 

<<snip older commits>> 
~/projects% 

Tym razem nie utknąłem całkowicie, ale nie miałbym ochoty robić takich rzeczy przez cały czas. (Oczekuję posiadania sporej liczby plików, które będą się ruszać co najmniej raz w życiu.)

Czy robię coś nie tak? Stara kopia pliku i nowa kopia są o 98,8% takie same (zmieniono 2 wiersze ze 166). Rozumiem, że git powinien być w stanie śledzić plik w tym przypadku, ponieważ sugeruje operacje zmiany nazwy, zamiast zapisywać je jawnie, a pliki są na tyle podobne, że uważam, że powinny one uważać je za takie same.

Czy jest coś, co mogę zrobić, aby to naprawić?

Answer 1

Odpowiadając na moje własne pytanie, ponieważ udało mi się zaspokoić moje obawy, nawet jeśli nie mam rozwiązać mój problem dokładnie. (git log --follow nadal nie działa dla mnie).

Po pierwsze, dziennik --summary dla zatwierdzenia zmiany nazwy zawiera linię delete ze starą nazwą pliku. Jeśli więc łatwo je zauważyć, możesz tam znaleźć jego starą nazwę i git log.

Jeśli jest to część dużego zatwierdzenia, a tym samym nieco trudniejszego do wykrycia - i ta sytuacja była jedną z moich obaw - można użyć git blame -C z nową nazwą pliku przy pierwszej wersji po zmianie nazwy. Przypuszczalnie linie pozostają z oryginalnego pliku! - więc git powinien znaleźć swoje źródło i pokazać starą nazwę pliku (i skrót mieszający dla dobrej miary). Następnie możesz podnieść ścieżkę przy pomocy git log.

Tak więc, jeśli interesuje Cię historia pliku jako jednostki (z jakiegokolwiek powodu), wydaje się, że można to zrobić stosunkowo prosto. Chociaż mam wrażenie, że git wolałby, żebyś go użył właściwie.

Answer 2

Cóż, ja widzę moje Zmienia nazwę z git log -M --summary ..

Answer 3

Proszę spróbować z git log --follow na swoim pliku. Uczę się stąd Is it possible to move/rename files in git and maintain their history?

Answer 4

git log --follow ./path/to/file 

Wierzę, że to jest to, czego szukasz.