Git winy nie pokazuje historii

88

Kiedy uruchamiam git blame na pliku (używając msysgit), zawsze otrzymuję następujący rodzaj wydruku:

00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   1) package co
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   2) {
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   3)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   4)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   5)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   6)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   7)      impor

tj. pokazuje wszystkie wiersze jako jeszcze niezatwierdzone.

Wypróbowałem to na wielu plikach, które mają wiele zatwierdzeń - zawsze te same wyniki. Próbowałem też użyć ścieżki względnej / pełnej, ale wydaje się, że nie robi to różnicy.

Kiedy próbuję wykorzystać winę TortoiseGit, zawsze pokazuje każdą linię jako ostatnią zatwierdzoną przy pierwszym zatwierdzeniu:

tekst alternatywny

nawet pomyślałem, jak już powiedziałem, w historii tych plików są dziesiątki zatwierdzeń.

Pomysły?

Edycja - więcej informacji

  • Git blame działa dobrze na GitHub, gdzie jest hostowane to repozytorium.
  • Działa również dobrze, jeśli sklonuję go na komputer z systemem Linux i obarczam winą tam
  • Wygląda na to, że tylko na msysgit to nie działa
git windows-subsystem-for-linux msysgit blame Assaf Lavie
źródło
Dla mnie ten problem wynikał z użycia ścieżki dowiązanej symbolicznie jako dołączonej do ścieżki rozpoznanej przez repozytorium, więc pomyślał, że plik jest całkowicie nowy.
Kzqai
Uwaga: Począwszy od git 2.0.1 (25 czerwca 2014 r.), Git winny powinien przestać zgłaszać wszystkie te wiersze „Jeszcze niezatwierdzone”. Zobacz moją odpowiedź poniżej
VonC
Na liście mailingowej: git.661346.n2.nabble.com/… Dzieje się również w systemie Linux.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
Dotyczy to również WSL, więc dodałem tag. Mam nadzieję, że wszystko w porządku.
mikemaccana

Odpowiedzi:

127

git blame file.txtobwinia wersję file.txt w kopii roboczej. Jeśli plik.txt ma w repozytorium znaki nowej linii Windows (CRLF), a ty je masz core.autocrlf = true, to każda linia pliku.txt zostanie uznana za inną i zostanie zgłoszona git blamejako jeszcze niezatwierdzona.

Powodem, dla którego git blame <my_branch>(lub nawet lepiej git blame HEAD, który działa bez względu na gałąź, w której się znajdujesz) jest to, że nie obwinia wersji roboczej kopii, więc nie ma możliwości, aby wiersze jeszcze nie zostały zatwierdzone.

kusma
źródło
118
git blame -wignoruje białe znaki, więc nadal możesz winić kopię roboczą, jeśli chcesz
Kyle Heironimus
13
Git blame -w powinna być odpowiedzią osobną i akceptowaną;). Zaakceptowana odpowiedź bez komentarza była dla mnie bezużyteczna.
Guillaume Perrot
55

Znalazłem rozwiązanie - bardzo dziwne.

Jeśli uruchomię to:

git blame file.txt

Historia jest zepsuta, jak napisano powyżej.

Jeśli zamiast tego zrobię to:

git blame my_branch file.txt

To działa!

To bardzo dziwne, ponieważ AFAICS użycie nie wymaga nazwy gałęzi:

$ git blame
usage: git blame [options] [rev-opts] [rev] [--] file
Assaf Lavie
źródło
7
To działa dla mnie, dzięki za opublikowanie. Powinieneś oznaczyć ten jako odpowiedź IMO.
wes
Działa to dla mnie w msysgit, ale w nazwie pliku jest rozróżniana wielkość liter. Więc mogę pisać git blame mybranch cmakelists.txti to się nie powiedzie; ale jeśli napiszę, git blame mybranch CMakeLists.txtto zadziała.
pętla
Zgadzam się, wes; wina polegała na braku historii, dopóki nie określiłem gałęzi, co jest niezgodne z dokumentacją.
josephdpurcell
OMG, wina jest tak zerwana.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
8

Począwszy od git 2.0.1 (25 czerwca 2014 r.), Git winny powinien przestać zgłaszać wszystkie te wiersze „Jeszcze niezatwierdzone”.

Zobacz popełnić 4d4813a (26 kwietnia 2014) przez brian m. carlson ( bk2204) .
(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu e934c67 , 06 czerwca 2014)

blame: poprawnie obsługuje pliki niezależnie od autocrlf

Jeśli plik zawierał CRLFzakończenia linii w repozytorium z core.autocrlf=input, wtedy obwiniaj linie zawsze oznaczane jako „ Not Committed Yet”, nawet jeśli były niezmodyfikowane.
Nie próbuj konwertować końcówek linii podczas tworzenia fałszywego zatwierdzenia, aby adnotacja działała poprawnie niezależnie od autocrlfustawienia.

VonC
źródło
8
Nadal mam problem w git v2.1.3
DBedrenko,
Mam problem z gitem w wersji 2.16.1.windows.1
Radon8472
@ Radon8472 Czy możesz dodać nowe pytanie ilustrujące problem, wraz z git config -lwynikami (i linkiem do tej odpowiedzi): to pozwoli mi i innym spróbować sprawdzić, czy problem nadal występuje.
VonC
1

Inna możliwość: literówka w nazwie pliku uwzględniająca wielkość liter

Miałem ten sam problem z git blame file.txt, a potem zdałem sobie sprawę, że wprowadziłem literówkę w nazwie pliku z rozróżnianiem wielkości liter w pliku file.txt

Zmieniłem go na File.txt (na przykład) i otrzymałem oczekiwane wyniki bez konieczności określenia my_branch: git blame File.txt

John Jacecko
źródło