Dlaczego git myśli, że każda linia nietkniętego pliku zmieniła się

Question

Nie sądzę, że jest to kwestia różnic kończących linię - p4merge nie uważa, że ​​w pliku nic się nie zmieniło, nawet jeśli ustawione jest rozpoznawanie różnic między wierszami i białymi odstępami między wierszami.

Mój problem jest to, że czasami zdarza się co następuje:

• Na pierwszy git status nie wykazuje niezatwierdzone zmiany.
• Następnie czekam na kolejną gałąź
• Teraz lista git status zawiera listę niektórych plików jako zmienione.
• git diff na każdym z tych "zmienionych plików" pokazuje wszystkie wiersze pliku jako zmienione. Zmieniona wersja wygląda tak samo jak wersja oryginalna.

Dlaczego tak się dzieje? Dlaczego Git sądzi, że pliki się zmieniły, kiedy wydaje się, że tego nie zrobiły? Dlaczego po prostu sprawdzenie innej gałęzi powoduje to?

Moja pierwsza myśl to końcówki linii, ale nie wiem, dlaczego p4merge ich nie wykrył. Drugim pomysłem były zmiany trybu plików. Nie wiem, jak się dowiedzieć, czy tak jest. git config --list pokazuje, że core.filemode ma wartość false. git config --global --list i git config --system --list nie wyświetlają żadnych ustawień dla core.filemode (mówię to tutaj, ponieważ nie jestem pewien, w jaki sposób różne poziomy konfiguracji zastępują się nawzajem). core.autocrlf jest ustawione na true.

Wielu programistów zatwierdza to samo repozytorium, od którego ściągam zmiany, wszystkie na komputerach z systemem Windows. Zgaduję, że ktoś gdzieś ma jakieś ustawienie na stanowisku, które to powoduje, ale nie wiem, czy to ja jestem lokalnie, czy ktoś inny, albo jakie to może być ustawienie.

Pliki wymienione jako zmienione nie wydają się być przypadkowe - jeśli usunę moje lokalne repozytorium, sklonować go ponownie z pilota (który domyślnie głównego oddziału jest wyrejestrowany), a kasa ta sama gałąź znowu git status list dokładnie te same pliki co zmienione, za każdym razem. Pliki są czasem czymś ostatnio edytowanym, czasem plikami, które nie zostały dotknięte od lat. Są to nie tylko pliki binarne (które czasami są uszkodzone przez pliki binarne), ale również pliki tekstowe.

Wykonywanie poleceń git rm --cached -r ., po którym następuje git reset --hard, pozbywa się zmian, ale zdarza się tak często, że robi się kłopotliwe. Jestem też ciekawy, co może być przyczyną tego.

To samo repozytorium powoduje również problemy z kończeniem linii. Myślę, że jest to osobny problem, więc prawdopodobnie skończę z kolejnym pytaniem, ale wspominam o tym tutaj na krótko, na wypadek, gdyby było ono powiązane. Sprawdzeniu inny oddział lub ciągnięcie zmiany ze zdalnego repozytorium plików powoduje czasami pojawiają się zmieniły i git diff na tych plików wyłącznie wyjście warning: LF will be replaced by CRLF in [file]. The file will have its original line endings in your working directory.

Edycja: Plik .gitattributes repozytorium ma tylko linię * text=auto i nic w nim.

Wyjście git config --list (pominięta ustawieniami rzeczy jak kolory, ścieżek plik do edytora, zdalnego, difftool, nazwę użytkownika i adres e-mail i takie):

core.symlinks=false 
core.autocrlf=true3 
pack.packsizelimit=2g 
rebase.autosquash=true 
merge.summary=true 
core.repositoryformatversion=0 
core.filemode=false 
core.bare=false 
core.logallrefupdates=true 
core.symlinks=false (yes this is there twice, just noticed) 
core.ignorecase=true 
core.hidedotfiles=dotgitOnly 

Answer 1

aby pokazać te „niewidoczne” zmiany w szczegółach używać:

git diff --word-diff-regex=. 

Zaznacza wszystkie zmienione znaki, nawet białe znaki.

Najprawdopodobniej pokaże zmianę zakończeń linii. Jeśli pracujesz w systemie Windows i włączyłeś core.autocrlf, git może oczekiwać innego rodzaju zakończenia linii i pokazać "złą" linię kończącą się jako diff.

Mówiąc git, nie przejmuj się końcówkami linii, wyłączając core.autocrlf, aby rozwiązać problem.