Jak „obwinić” usuniętą linię?

git blamejest świetny dla zmodyfikowanych i dodanych linii, ale jak mogę znaleźć, kiedy linia, która istniała w określonym poprzednim zatwierdzeniu została ostatecznie usunięta. Myślębisect , ale liczyłem na coś wygodniejszego.

(Zanim zapytasz: w tym przypadku właśnie zrobiłem a git log -pi przeszukałem linię kodu i (a) jakiś idiota właśnie usunął kluczową linię z poprzedniego zatwierdzenia i (b) byłem tym idiotą).

Jeśli znasz treść wiersza, jest to idealny przypadek użycia dla:

git log -S <string> path/to/file

który pokazuje zatwierdzenia, które wprowadzają lub usuwają wystąpienie tego ciągu. Jest też to, -G<regex>co robi to samo z wyrażeniami regularnymi! Zobacz man git-logi poszukiwanie -Gi -Sopcji, lub kilof (przyjazna nazwa dla tych funkcji), aby uzyskać więcej informacji.

The -SOpcja jest faktycznie wymienione w nagłówku git-blamemanpage też, w części opisu, w którym podaje przykład używając git log -S....

Myślę, że tak naprawdę chcesz

git blame --reverse START..END filename

Z strony podręcznika :

Przejdź historię do przodu zamiast do tyłu. Zamiast pokazywania wersji, w której pojawiła się linia, pokazuje ostatnią wersję, w której linia istniała. Wymaga to szeregu zmian, takich jak START..END, gdzie ścieżka do winy istnieje w START.

Z git blame reverse możesz znaleźć ostatnie zatwierdzenie, w którym pojawiła się linia. Nadal musisz uzyskać zatwierdzenie, które nastąpi po.

Możesz użyć następującego polecenia, aby wyświetlić odwrócony dziennik git. Pierwsze pokazane zatwierdzenie będzie ostatnim wyświetleniem tego wiersza, a następne zatwierdzenie nastąpi, gdy zostanie zmienione lub usunięte.

git log --reverse --ancestry-path COMMIT^..master

Aby wypełnić odpowiedź Cascabel :

git log --full-history -S <string> path/to/file

Miałem ten sam problem, jak tutaj wspomniany, ale okazało się, że brakuje linii, ponieważ zatwierdzenie scalania z gałęzi zostało cofnięte, a następnie scalone z powrotem, skutecznie usuwając daną linię. W --full-historyzapobiega flag omijając te rewizje.

git winę --reverse może dostać się blisko do miejsca, gdzie linia zostanie usunięty. Ale tak naprawdę nie jest wskazuje wersji, w której wiersz jest usuwany. Wskazuje na ostatnią wersję, w której linia była obecna . Następnie, jeśli następująca wersja jest zwykłym zatwierdzeniem, masz szczęście i masz usuniętą wersję. OTOH, jeśli następująca wersja jest zatwierdzeniem scalania , sprawy mogą stać się trochę dzikie.

W ramach wysiłku stworzenia difflame rozwiązałem ten problem, więc jeśli masz już zainstalowanego Pythona na swoim urządzeniu i chcesz spróbować, nie czekaj dłużej i daj mi znać, jak to działa.

https://github.com/eantoranz/difflame

W przypadku zmian ukrytych w zatwierdzeniach scalania

Polecenia scalania automatycznie ukrywają swoje zmiany w danych wyjściowych dziennika Git. Zarówno kilof, jak i odwrotna wina nie znalazły zmiany. Więc wiersz, który chciałem został dodany, a później usunięty, i chciałem znaleźć scalenie, które go usunęło. git log -p -- path/fileHistoria plików pokazuje tylko, że jest dodawana. Oto najlepszy sposób na znalezienie tego:

git log -p -U9999 -- path/file

Wyszukaj zmianę, a następnie wyszukaj wstecz „^ commit” - pierwsze „^ commit” to zatwierdzenie, w którym plik miał ostatnią linię. Drugie „zatwierdzenie” następuje po jego zniknięciu. Drugim zatwierdzeniem może być ten, który go usunął. The-U9999 on wyświetlać całą zawartość pliku (po każdej zmianie pliku), przy założeniu, że wszystkie pliki mają maksymalnie 9999 wierszy.

Znajduje wszelkie powiązane scalenia za pomocą brutalnej siły (różni każde możliwe scalenie zatwierdzenia z pierwszym rodzicem, działa przeciwko tonom commits)

git log --merges --pretty=format:"git diff %h^...%h | grep target_text" HEAD ^$(git merge-base A B) | sh -v 2>&1 | less

(Próbowałem bardziej ograniczyć filtr wersji, ale natknąłem się na problemy i nie polecam tego. Poszukiwane zmiany dodawania / usuwania dotyczyły różnych gałęzi, które zostały scalone w różnym czasie i A ... B nie obejmował kiedy zmiany faktycznie zostały scalone z linią główną).

Pokaż drzewo Git z tymi dwoma zatwierdzeniami (i usunięto wiele złożonych historii Git):

git log --graph --oneline A B ^$(git merge-base A B) (A jest pierwszym zatwierdzeniem powyżej, B jest drugim zatwierdzeniem powyżej)

Pokaż historię A i historię B minus historię zarówno A, jak i B.

Alternatywna wersja (wydaje się, że pokazuje ścieżkę bardziej liniowo niż zwykłe drzewo historii Git - jednak wolę zwykłe drzewo historii Git):

git log --graph --oneline A...B

Trzy, a nie dwie kropki - trzy kropki oznaczają „r1 r2 - nie $ (git merge-base - all r1 r2). Jest to zestaw zatwierdzeń, które są osiągalne z jednego z r1 (lewa strona) lub r2 (prawa strona) z boku), ale nie z obu ”. - źródło: „man gitrevisions”