Jak NAPRAWDĘ wyświetlić logi plików o zmienionych nazwach za pomocą git?

Jestem stosunkowo nowy w git. Wcześniej korzystałem z Subversion.

Zauważyłem, że większość graficznych interfejsów Git i wtyczek IDE nie wydaje się być w stanie wyświetlić historii pliku, jeśli nazwa pliku została zmieniona. Kiedy używam

git log --follow

w wierszu poleceń widzę cały dziennik po zmianie nazw.

Według Linusa Torvaldsa ( link alternatywny ) --followprzełącznik jest przyjemny dla „noob SVN”; poważni użytkownicy Git nie używają go:

--follow to totalny hack, mający po prostu zadowolić byłych użytkowników SVN, którzy i tak nigdy nie wiedzieli nic o takich rzeczach, jak rodzicielstwo czy ładne wykresy wersji.

Nie jest to całkowicie fundamentalne, ale obecna implementacja "--follow" jest naprawdę szybkim procesem wstępnym, przykręconym do logiki chodzenia po rewizji, a nie jest czymś naprawdę integralnym.

Dosłownie został zaprojektowany jako przyjemny element „SVN noob”, a nie jako „prawdziwa funkcjonalność gita”. Pomysł polegał na tym, że oderwałbyś się od (zepsutego) sposobu myślenia, że ​​zmiana nazwy ma znaczenie w szerszym kontekście.

Moje pytanie : W jaki sposób zagorzali użytkownicy git wśród was uzyskują historię pliku po zmianie jego nazwy? Jaki jest „prawdziwy” sposób na zrobienie tego?

Myślę, że głównym motywem przewodnim Linusa jest to, że - i weź to z przymrużeniem oka - hardkorowi użytkownicy gita nigdy nie przejmują się historią „pliku”. Umieszczasz zawartość w repozytorium git, ponieważ zawartość jako całość ma znaczącą historię.

Zmiana nazwy pliku to mały, specjalny przypadek „zawartości” przemieszczającej się między ścieżkami. Możesz mieć funkcję, która przenosi się między plikami, które użytkownik git może śledzić za pomocą „kilofa” (np log -S.).

Inne zmiany „ścieżki” obejmują łączenie i dzielenie plików; git tak naprawdę nie obchodzi, który plik uważasz za zmieniony, a który uważasz za skopiowany (lub zmieniony i usunięty), po prostu śledzi całą zawartość twojego drzewa.

git zachęca do myślenia „całym drzewem”, gdzie wiele systemów kontroli wersji jest bardzo skoncentrowanych na plikach. To dlatego git częściej odwołuje się do „ścieżek” niż do „nazw plików”.

Mam dokładnie ten sam problem, z którym masz do czynienia. Chociaż nie mogę udzielić ci odpowiedzi, myślę, że możesz przeczytać tego e-maila, który Linus napisał w 2005 roku, jest on bardzo trafny i może dać ci wskazówkę, jak rozwiązać problem:

… Twierdzę, że każdy SCM, który próbuje śledzić zmiany nazw, jest zasadniczo zepsuty, chyba że robi to z przyczyn wewnętrznych (tj. W celu umożliwienia efektywnych delt), dokładnie dlatego, że zmiany nazw nie mają znaczenia. Oni nie pomóc, a nie są one co byli zainteresowani w każdym razie .

Liczy się znalezienie „skąd się to wzięło”, a architektura git robi to naprawdę bardzo dobrze - znacznie lepiej niż cokolwiek innego. …

Znalazłem odniesienie do tego posta na blogu, który może być również przydatny w znalezieniu realnego rozwiązania:

W wiadomości Linus nakreślił, w jaki sposób idealny system śledzenia treści może pozwolić ci dowiedzieć się, w jaki sposób blok kodu przybrał obecny kształt. Zacząłbyś od bieżącego bloku kodu w pliku, cofnął się do historii, aby znaleźć zatwierdzenie, które zmieniło plik. Następnie sprawdzasz zmianę zatwierdzenia, aby zobaczyć, czy interesujący Cię blok kodu jest przez nią modyfikowany, ponieważ zatwierdzenie zmieniające plik może nie dotknąć bloku kodu, który Cię interesuje, ale tylko niektóre inne części plik.

Kiedy stwierdzisz, że przed zatwierdzeniem blok kodu nie istniał w pliku, przyjrzyj się dokładniej zatwierdzeniu. Może się okazać, że jest to jedna z wielu możliwych sytuacji, w tym:

1. Zatwierdzenie naprawdę wprowadziło blok kodu. Autorem zmiany był twórca tej fajnej funkcji, na którą polowałeś, jej pochodzenie (lub winny, który wprowadził błąd); lub
2. Blok kodu nie istniał w pliku, ale pięć identycznych kopii znajdowało się w różnych plikach, z których wszystkie zniknęły po zatwierdzeniu. Autor zatwierdzenia refaktoryzował zduplikowany kod, wprowadzając pojedynczą funkcję pomocniczą; lub
3. (w szczególnym przypadku) Przed zatwierdzeniem plik, który aktualnie zawiera blok interesującego nas kodu, sam nie istniał, ale istniał inny plik o prawie identycznej zawartości, a blok kodu, który Cię interesował, wraz z całą pozostałą zawartością w pliku istniała wtedy, istniała w tym innym pliku. Odeszło po zatwierdzeniu. Autor zatwierdzenia zmienił nazwę pliku, wprowadzając niewielką modyfikację.

W git, najlepsze narzędzie Linusa do śledzenia treści nie istnieje jeszcze w pełni zautomatyzowany sposób. Ale większość ważnych składników jest już dostępna.

Prosimy o informowanie nas o swoich postępach w tej sprawie.

Zauważyłem, że większość graficznych interfejsów git i wtyczek IDE nie wydaje się być w stanie wyświetlić historii pliku, jeśli nazwa pliku została zmieniona

Z przyjemnością dowiesz się, że niektóre popularne narzędzia interfejsu użytkownika Git obsługują to teraz. Istnieją dziesiątki narzędzi Git UI, więc nie będę ich wszystkich wymieniać, ale na przykład:

• SourceTree podczas przeglądania dziennika plików ma w lewym dolnym rogu pole wyboru „Śledź pliki o zmienionej nazwie”
• TortoiseGit ma pole wyboru „śledź zmiany nazw” w oknie dziennika w lewym dolnym rogu.

Więcej informacji o narzędziach interfejsu użytkownika Git:

• http://git-scm.com/downloads/guis
• https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools

Uwaga: git 2.9 (czerwiec 2016) poprawi nieco "błędny" charakter git log --follow:

Zobacz commit ca4e3ca (30 marca 2016) autorstwa SZEDER Gábor ( szeder) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zobowiązaniu 26effb8 , 13 kwietnia 2016 r.)}

diffcore: napraw kolejność iteracji identycznych plików podczas wykrywania zmiany nazwy

Jeśli dwie ścieżki „ dir/A/file” i „ dir/B/file” mają identyczną treść, a nazwa katalogu nadrzędnego została zmieniona, np. „ git mv dir other-dir”, diffcoreZgłasza następujące dokładne zmiany:

renamed:    dir/B/file -> other-dir/A/file
renamed:    dir/A/file -> other-dir/B/file

(zwróć uwagę na inwersję tutaj: B/file -> A/filei A/file -> B/file)

Chociaż technicznie nie jest źle, jest to mylące nie tylko dla użytkownika, ale także dla poleceń git, które podejmują decyzje na podstawie informacji o zmianie nazwy, np. git log --follow other-dir/A/file„Podąża” dir/B/fileza zmianą nazwy.

To zachowanie jest efektem ubocznym zatwierdzenia v2.0.0-rc4 ~ 8 ^ 2 ~ 14 ( diffcore-rename.c: uprość znajdowanie dokładnych zmian nazw, 2013-11-14): źródła przechowujące hashmap zwracają wpisy z tego samego zasobnika, tj. Źródła pasujące do bieżącego miejsca docelowego , w kolejności LIFO.
W związku z tym iteracja najpierw sprawdza „ other-dir/A/file” i „ dir/B/file”, a po znalezieniu identycznej treści i podstawowej nazwy zgłasza dokładną zmianę nazwy.

W systemie Linux sprawdziłem, że SmartGit i GitEye są w stanie śledzić zmiany nazw podczas śledzenia historii określonego pliku. Jednak w przeciwieństwie do gitk i GitEye, SmartGit pokazuje osobny widok plików i widok repozytorium (który zawiera strukturę katalogów, ale nie zawiera listy plików)