Pliki wyświetlane jako zmodyfikowane bezpośrednio po git clone

Miałem ten sam problem na Macu po klonowaniu repo, zakładam, że wszystkie pliki zostały zmienione.

Po uruchomieniu {[1] } nadal oznaczał wszystkie pliki jako zmienione. Po szukaniu poprawki natknąłem się na .gitattributes plik w katalogu domowym, który miał następujący

* text=auto

Skomentowałem to i wszystkie inne sklonowane repozytoria od teraz działają dobrze. Mam nadzieję, że to komuś pomoże.

git config core.fileMode false

Rozwiązałem ten problem w moim przypadku

Https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html

TL;DR;

Rdzeń.fileMode

Jeśli false, to różnice bitów wykonywalnych pomiędzy indeksem a drzewem roboczym są ignorowane; przydatne na zepsutych systemach plików, takich jak FAT. Patrz git-update-index(1).

Wartość domyślna jest true, z wyjątkiem git-clone(1) lub git-init(1) będzie sprawdzać i ustawiać core.fileMode false, jeśli jest to właściwe, gdy repozytorium jest stworzony.

Zakładam, że używasz Windows. Ta strona github, którą podlinkowałeś, zawiera szczegóły od tyłu. Problem polega na tym, że zakończenia linii CRLF zostały już przypisane do repo i dlatego, że masz core.autocrlf ustawiony na true lub input, git chce przekonwertować zakończenia linii na LF tak git status pokazuje, że każdy plik został zmieniony.

Jeśli jest to repo, do którego chcesz tylko uzyskać dostęp, ale nie masz z nim nic wspólnego, możesz uruchomić następujące polecenie, aby ukryć problem bez faktycznego rozwiązania.

git config core.autocrlf false

Poniższy tekst pochodzi bezpośrednio ze strony podręcznika gitattributes i powinien być preformowany z czystego, działającego katalog.

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 jakiekolwiek pliki, które nie powinny być znormalizowane, pojawią się w git status, odłącz ich atrybut tekstowy przed uruchomieniem git add -u.

manual.pdf      -text

Odwrotnie, pliki tekstowe, których git nie wykrywa, mogą mieć normalizację włączoną ręcznie.

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

W Visual Studio, jeśli używasz Git, możesz automatycznie wygenerować .gitignore i .gitattributes files. Auto wygenerowane .plik getattributes ma następującą linię:

* text=auto

Ta linia znajduje się w pobliżu górnej części pliku. Po prostu musieliśmy skomentować linię, dodając # z przodu. Po zrobieniu tego, wszystko działało zgodnie z oczekiwaniami.

Problem może wynikać również z różnych uprawnień plików , Jak to było w moim przypadku:

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

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

Bare remote repozytorium (Linux):

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

Miałem ten sam problem. Również z Mac. Patrząc na repo na Linuksie zauważyłem, że mam dwa pliki:

Geoip.dat i GeoIP.dat

Usunięto przestarzałe repozytorium na komputerze z Linuksem i ponownie sklonowano repozytorium na komputerze mac. Nie byłem w stanie wyciągnąć, zatwierdzić, ukryć lub wyciągnąć z mojej kopii repozytorium, gdy były duplikaty.

Chciałem dodać odpowiedź bardziej ukierunkowaną na "dlaczego" tak się dzieje, ponieważ jest już dobra odpowiedź na to, jak to naprawić.

Tak więc, .gitattributes ma ustawienie * text=auto, które powoduje ten problem.

W moim przypadku pliki na gałęzi master Githuba miały \r\n zakończenia. Wybrałem ustawienia w repo, aby sprawdzić się z zakończeniami \n. Ale nie wiem, co git sprawdza. Ma się sprawdzać z natywnymi zakończeniami na moim Linuksie (\n), ale chyba sprawdził plik z zakończeniami \r\n. Git narzeka, ponieważ widzi zakończenia wypisane \r\n, które były w repo i ostrzega mnie, że będzie sprawdzać ustawienia \n. Stąd pliki są "do modyfikacji".

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

Było to spowodowane tym, że ścieżka do pliku i nazwa pliku były zbyt długie dla systemu Windows. Aby rozwiązać problem Sklonuj repo jak najbliżej katalogu głównego dysku twardego aby zmniejszyć długość ścieżki do pliku np. Sklonuj do C:\A\GitRepo zamiast C:\Users Documents\yyy \ Desktop\GitRepo

Edycja pliku o nazwie: sudo gedit .git/config sudo vim .git/config

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = [email protected]: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 = true na filemode = false

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

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

*.psd binary

Miałem podobny problem i znalazłem to pytanie.

Próbowałem zrobić interaktywną rebase, ale twierdził, że są jakieś zmodyfikowane pliki, więc nie pozwolił mi zrobić tego teraz. Próbowałem wszystkiego, aby wrócić do czystego repo, 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'

Ale dodaję To rozwiązanie tutaj, więc może jeśli kiedykolwiek wpadnę na to jeszcze raz zobaczę to i spróbuję. Dzięki: D