Pliki wyświetlane jako zmodyfikowane bezpośrednio po klonie Git

W tej chwili mam problem z repozytorium i chociaż mój Git-fu jest zwykle dobry, nie mogę go rozwiązać.

Kiedy sklonuję to repozytorium, a następnie cddo repozytorium, git statuspokazuje kilka plików jako zmienionych. Uwaga: Nie otworzyłem repozytorium w żadnym edytorze ani niczym.

Próbowałem postępować zgodnie z tym przewodnikiem: http://help.github.com/dealing-with-lineendings/ , ale to wcale nie pomogło w moim problemie.

Próbowałem git checkout -- .wiele razy, ale wydaje się, że nic nie robię.

Jestem na komputerze Mac i w samym repozytorium nie ma podmodułów.

System plików to „Journaled HFS +” na komputerze Mac i nie rozróżnia wielkości liter. Pliki są jednowierszowe i po około 79 KB każdy (tak, dobrze słyszałeś), więc patrzenie na git diffnie jest szczególnie pomocne. Słyszałem o robieniu, git config --global core.trustctime falseco może pomóc, co spróbuję, gdy wrócę do komputera z repozytorium.

Zmieniłem szczegóły systemu plików o fakty! I spróbowałem git config --global core.trustctime falsesztuczki, która nie działała zbyt dobrze.

Miałem ten sam problem na komputerze Mac po sklonowaniu repozytorium. Zakłada się, że wszystkie pliki zostały zmienione.

Po uruchomieniu git config --global core.autocrlf inputnadal oznaczał wszystkie pliki jako zmienione. Po szukaniu poprawki natknąłem się na .gitattributesplik w katalogu domowym, który miał następujące elementy.

* text=auto

Skomentowałem to i wszelkie inne sklonowane repozytoria odtąd działały dobrze.

Mam to. Wszyscy inni programiści korzystają z systemu Ubuntu (tak myślę), a zatem mają systemy plików z rozróżnianiem wielkości liter. Ja jednak tego nie robię (jak na komputerze Mac). Rzeczywiście, wszystkie pliki miały małe bliźniaki, kiedy na nie spojrzałem git ls-tree HEAD <path>.

Poproszę jednego z nich, żeby to rozwiązał.

git config core.fileMode false

rozwiązałem ten problem w moim przypadku

https://git-scm.com/docs/git-config

TL; DR;

core.fileMode

W przypadku wartości false różnice w wykonywalnych bitach między indeksem a drzewem roboczym są ignorowane; przydatne na uszkodzonych systemach plików, takich jak FAT. Zobacz git-update-index (1).

Domyślnie jest to prawda, z wyjątkiem tego, że git-clone (1) lub git-init (1) sondują i ustawią core.fileMode na false, jeśli to właściwe, podczas tworzenia repozytorium.

Zakładam, że używasz systemu Windows. Ta strona GitHub, do której prowadzisz link, zawiera szczegóły wstecz. Problem polega na tym, że zakończenia linii CR + LF zostały już przypisane do repozytorium, a ponieważ w pliku core.autocrlf ustawiono wartość true lub input , Git chce przekonwertować zakończenia linii na LF, więcgit status pokazuje, że każdy plik jest zmieniany.

Jeśli jest to repozytorium, do którego chcesz tylko uzyskać dostęp, ale z którym nie masz żadnego związku, możesz uruchomić następujące polecenie, aby po prostu ukryć problem bez jego rozwiązania.

git config core.autocrlf false

Jeśli jest to repozytorium, w które będziesz aktywnie uczestniczyć i możesz zatwierdzać zmiany. Możesz rozwiązać problem, wykonując zatwierdzenie, które zmienia wszystkie zakończenia linii w repozytorium, aby używało LF zamiast CR + LF, a następnie podejmuje kroki, aby zapobiec ponownemu wystąpieniu w przyszłości.

Poniższe informacje pochodzą bezpośrednio ze strony podręcznika gitattributes i powinny zostać wykonane z czystego katalogu roboczego.

echo "* text=auto" >>.gitattributes
rm .git/index     # Remove the index to force Git to
git reset         # re-scan the working directory.
git status        # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

Jeśli pojawią się pliki, które nie powinny być znormalizowane git status, przed uruchomieniem wyłącz ich atrybut tekstowy git add -u.

manual.pdf      -text

I odwrotnie, w plikach tekstowych, których Git nie wykrywa, można ręcznie włączyć normalizację.

weirdchars.txt  text

Uruchom następujące polecenia. To może rozwiązać problem.

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

Jeśli używasz Git w Visual Studio, możesz automatycznie wygenerować pliki .gitignore i .gitattributes. Automatycznie wygenerowany plik .getattributes ma następujący wiersz:

* text=auto

Ta linia znajduje się w górnej części pliku. Musieliśmy tylko skomentować linię, dodając # z przodu. Po wykonaniu tej czynności wszystko działało zgodnie z oczekiwaniami.

Problem może również wynikać z różnych uprawnień do plików , tak jak w moim przypadku:

Świeżo sklonowane repozytorium (Windows, Cygwin):

$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Bare zdalne repozytorium (Linux):

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Chciałem dodać odpowiedź bardziej ukierunkowaną na „Dlaczego” tak się dzieje, ponieważ już istnieje dobra odpowiedź na to, jak to naprawić.

Tak, .gitattributesma * text=autoustawienie, które powoduje ten problem.

W moim przypadku pliki w gałęzi głównej GitHub miały \r\nkońcówki. Wywołałem ustawienia w repozytorium, aby dokonać odprawy z \nzakończeniami. Nie wiem jednak, co Git sprawdza. Ma wypisywać się z natywnymi zakończeniami na moim Linux-ie ( \n), ale chyba wypisał plik z \r\nzakończeniami. Git narzeka, ponieważ widzi wyrejestrowane \r\nzakończenia znajdujące się w repozytorium i ostrzega mnie, że sprawdzi \nustawienia. Dlatego pliki należy „modyfikować”.

Na razie to rozumiem.

Miałem ten sam problem. Również z komputerem Mac. Przeglądając repozytorium na komputerze z systemem Linux zauważyłem, że mam dwa pliki:

geoip.dat i GeoIP.dat

Usunąłem przestarzały na komputerze z systemem Linux i ponownie sklonowałem repozytorium na komputerze Mac. Nie mogłem wyciągać, zatwierdzać, ukrywać ani wyciągać z mojej kopii repozytorium, gdy były duplikaty.

Ten sam problem dla mnie. Widziałem kilka obrazów o tej samej nazwie, takich jak „textField.png” i „textfield.png” w zdalnym repozytorium Git, ale nie w moim lokalnym repozytorium. Mogłem zobaczyć tylko „textField.png”, który nie został użyty w kodzie projektu.

Okazuje się, że większość moich kolegów korzysta z systemu Ubuntu przy użyciu systemu plików ext4, a ja korzystam z komputera Mac z systemem APFS.

Dzięki odpowiedzi Sama Elliotta rozwiązanie było dość proste. Najpierw poprosiłem kolegę z Ubuntu, aby usunął zbędne wersje plików wielkimi literami, a następnie zatwierdził i wcisnął zdalnie.

Następnie wykonałem następujące czynności:

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

Wreszcie zdecydowaliśmy, że każdy programista powinien zmienić konfigurację Git, aby zapobiec powtórzeniu się tego problemu:

# Local Git configuration
git config core.ignorecase = true

lub

# Global Git configuration
git config --global core.ignorecase = true

Miałem też ten sam problem. W moim przypadku sklonowałem repozytorium i niektóre pliki natychmiast zniknęły.

Przyczyną było to, że ścieżka do pliku była zbyt długa dla systemu Windows. Aby rozwiązać ten problem, sklonuj repozytorium jak najbliżej katalogu głównego dysku twardego, aby skrócić długość ścieżki do pliku. Na przykład sklonuj go do C:\A\GitRepozamiast C:\Users Documents\yyy\Desktop\GitRepo.

Edytuj plik o nazwie .git/config:

sudo gedit .git/config

Lub:

sudo vim .git/config

Zawartość

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true

[remote "origin"]
    url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
    remote = origin
    merge = refs/heads/master

[branch "productapproval"]
    remote = origin
    merge = refs/heads/productapproval

Zmień filemode=truena filemode = false.

W przypadku nowych wersji systemu macOS może to być spowodowane funkcją zabezpieczeń systemu operacyjnego.

W repozytorium, nad którym pracowałem, był plik binarny o typie pliku * .app.

To tylko niektóre dane zserializowane, ale macOS traktuje wszystkie pliki * .app jako aplikację i ponieważ użytkownik nie pobrał tego pliku, system uznał go za niebezpieczny i dodał com.apple.quarantineatrybut pliku, który zapewnia, że ​​plik nie może zostać wykonany.

Ale ustawienie tego atrybutu na pliku również zmieniało plik i dlatego pojawił się w zestawie zmian Git bez możliwości przywrócenia go.

Możesz sprawdzić, czy masz ten sam problem, uruchamiając $ xattr file.app.

Rozwiązanie jest dość proste, o ile nie musisz pracować z plikiem. Po prostu dodaj *.app binarydo swojego .gitattributes.

Skopiowałem moje lokalne repozytorium do innego folderu i pojawiło się kilka zmodyfikowanych plików. Moje obejście: ukryłem zmodyfikowane pliki i usunąłem ukryty plik . Repozytorium stało się czyste.

Odkryłem, że Git traktuje moje pliki (w tym przypadku .psd) jako tekst. Ustawienie go na typ binarny w .gitattributes rozwiązało to.

*.psd binary

Próbowałem zrobić interaktywny rebase, ale twierdził, że są jakieś zmodyfikowane pliki, więc nie pozwoli mi to teraz zrobić. Próbowałem wszystkiego, aby wrócić do czystego repozytorium, ale nic nie działało. Żadna z pozostałych odpowiedzi nie pomogła. Ale to w końcu zadziałało ...

git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'

Bum! Wyczyść repozytorium. Problem rozwiązany. Potem musiałem po prostu zrezygnować z ostatniego zatwierdzenia, kiedy to zrobiłem, rebase -ii wreszcie wszystko znów było czyste. Dziwaczny!

Na wypadek, gdyby pomógł komuś innemu, może być inna przyczyna tego problemu: różne wersje Git. Używałem domyślnie zainstalowanej wersji Git na polu Ubuntu 18.04 (Bionic Beaver) i wszystko działało dobrze, ale kiedy próbowałem sklonować repozytorium przy użyciu Git na Ubuntu 16.04, niektóre pliki były wyświetlane jako zmodyfikowane.

Żadna z pozostałych odpowiedzi tutaj nie rozwiązała mojego problemu, ale uaktualnienie wersji Git w celu dopasowania w obu systemach naprawiło problem.