Dateien, die direkt nach einem Git-Klon als geändert angezeigt werden

Ich habe momentan ein Problem mit einem Repository und obwohl mein Git-Fu normalerweise gut ist, kann ich dieses Problem anscheinend nicht lösen.

Wenn ich dieses Repository klone, cdwerden im Repository git statusmehrere Dateien als geändert angezeigt. Hinweis: Ich habe das Repository in keinem Editor oder etwas anderem geöffnet.

Ich habe versucht, diesem Handbuch zu folgen: http://help.github.com/dealing-with-lineendings/ , aber dies hat bei meinem Problem überhaupt nicht geholfen.

Ich habe es git checkout -- .oft versucht , aber es scheint nichts zu tun.

Ich bin auf einem Mac und es gibt keine Submodule im Repository selbst.

Das Dateisystem ist auf dem Mac das Dateisystem "Journaled HFS +" und unterscheidet nicht zwischen Groß- und Kleinschreibung. Die Dateien sind einzeilig und haben jeweils eine Größe von ca. 79 KB (ja, Sie haben richtig gehört). Daher ist das Betrachten git diffnicht besonders hilfreich. Ich habe davon gehört, git config --global core.trustctime falsewas helfen könnte, was ich versuchen werde, wenn ich mit dem darauf befindlichen Repository zum Computer zurückkehre.

Ich habe Details des Dateisystems mit Fakten geändert! Und ich habe den git config --global core.trustctime falseTrick ausprobiert, der nicht sehr gut funktioniert hat.

Ich hatte das gleiche Problem auf dem Mac, nachdem ich ein Repository geklont hatte. Es würde davon ausgegangen, dass alle Dateien geändert wurden.

Nach dem Ausführen git config --global core.autocrlf inputwurden immer noch alle Dateien als geändert markiert. Nachdem ich nach einem Fix gesucht hatte, stieß ich auf eine .gitattributesDatei im Home-Verzeichnis, die Folgendes enthielt.

* text=auto

Ich habe es auskommentiert und alle anderen geklonten Repositories funktionierten von nun an einwandfrei.

Ich habe es verstanden. Alle anderen Entwickler arbeiten unter Ubuntu (glaube ich) und haben daher Dateisysteme, bei denen zwischen Groß- und Kleinschreibung unterschieden wird. Ich jedoch nicht (da ich auf einem Mac bin). In der Tat hatten alle Dateien Zwillinge in Kleinbuchstaben, als ich sie mir mit ansah git ls-tree HEAD <path>.

Ich werde einen von ihnen bitten, das zu klären.

git config core.fileMode false

löste dieses Problem in meinem Fall

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

TL; DR;

core.fileMode

Bei false werden die ausführbaren Bitunterschiede zwischen dem Index und dem Arbeitsbaum ignoriert. nützlich auf kaputten Dateisystemen wie FAT. Siehe git-update-index (1).

Der Standardwert ist true, außer dass git-clone (1) oder git-init (1) core.fileMode prüfen und gegebenenfalls auf false setzen, wenn das Repository erstellt wird.

Ich gehe davon aus, dass Sie Windows verwenden. Die GitHub-Seite, auf die Sie verlinkt haben, enthält die Details rückwärts. Das Problem ist, dass CR + LF-Zeilenenden bereits in das Repository übernommen wurden. Da Sie core.autocrlf entweder auf true oder auf input gesetzt haben , möchte Git die Zeilenenden in LF konvertierengit status zeigt, dass jede Datei geändert wird.

Wenn dies ein Repository ist, auf das Sie nur zugreifen möchten, an dem Sie jedoch nicht beteiligt sind, können Sie den folgenden Befehl ausführen, um das Problem lediglich auszublenden, ohne es tatsächlich zu lösen.

git config core.autocrlf false

Wenn dies ein Repository ist, an dem Sie aktiv beteiligt sind und an dem Sie Änderungen vornehmen können. Möglicherweise möchten Sie das Problem beheben, indem Sie ein Commit durchführen, bei dem alle Zeilenenden im Repository so geändert werden, dass LF anstelle von CR + LF verwendet wird, und dann Maßnahmen ergreifen, um zu verhindern, dass es in Zukunft erneut auftritt.

Das Folgende stammt direkt aus der Manpage gitattributes und sollte aus einem sauberen Arbeitsverzeichnis erstellt werden.

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"

Wenn Dateien git statusangezeigt werden, die nicht normalisiert werden sollen , deaktivieren Sie deren Textattribut, bevor Sie ausgeführt werden git add -u.

manual.pdf      -text

Umgekehrt kann bei Textdateien, die Git nicht erkennt, die Normalisierung manuell aktiviert werden.

weirdchars.txt  text

Bitte führen Sie die folgenden Befehle aus. Das könnte das Problem lösen.

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

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

Wenn Sie in Visual Studio Git verwenden, können Sie die Dateien .gitignore und .gitattributes automatisch generieren. Die automatisch generierte .getattributes-Datei enthält die folgende Zeile:

* text=auto

Diese Zeile befindet sich oben in der Datei. Wir mussten nur die Zeile kommentieren, indem wir ein # an der Vorderseite hinzufügen. Danach liefen die Dinge wie erwartet.

Das Problem kann auch durch unterschiedliche Dateiberechtigungen entstehen , wie in meinem Fall:

Frisch geklontes Repository (Windows, Cygwin):

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

Bare Remote-Repository (Linux):

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

Ich wollte eine Antwort hinzufügen, die mehr auf "Warum" gerichtet ist, da dies bereits eine gute Antwort darauf gibt, wie dies behoben werden kann.

Hat .gitattributesalso eine * text=autoEinstellung, die dieses Problem verursacht.

In meinem Fall hatten Dateien im Hauptzweig von GitHub \r\nEndungen. Ich habe die Einstellungen im Repository gewählt, um mit \nEndungen einzuchecken . Ich weiß allerdings nicht, was Git auscheckt. Es soll mit nativen Endungen auf meiner Linux-Box ( \n) ausgecheckt werden, aber ich denke, es hat die Datei mit \r\nEndungen ausgecheckt. Git beschwert sich, weil es die ausgecheckten \r\nEndungen sieht , die sich im Repository befanden, und warnt mich, dass es \nEinstellungen eincheckt . Daher müssen Dateien "geändert werden".

Das ist mein Verständnis für jetzt.

Ich hatte das gleiche Problem. Auch mit einem Mac. Beim Betrachten des Repositorys auf einem Linux-Computer stellte ich fest, dass ich zwei Dateien hatte:

geoip.dat und GeoIP.dat

Ich habe das veraltete auf dem Linux-Computer entfernt und das Repository erneut auf den Mac geklont. Ich konnte meine Kopie des Repositorys nicht abrufen, festschreiben, verstauen oder abrufen, wenn Duplikate vorhanden waren.

Das gleiche Problem für mich. Ich konnte mehrere Bilder mit demselben Namen wie "textField.png" und "textfield.png" im Remote-Git-Repository sehen, aber nicht in meinem lokalen Repository. Ich konnte nur "textField.png" sehen, das im Projektcode nicht verwendet wurde.

Es stellt sich heraus, dass die meisten meiner Kollegen unter Ubuntu das ext4- Dateisystem verwenden, während ich mit APFS auf einem Mac bin.

Dank der Antwort von Sam Elliott war die Lösung recht einfach. Zuerst habe ich einen Kollegen unter Ubuntu gebeten, die redundanten Dateiversionen mit Großbuchstaben zu löschen, dann festzuschreiben und auf Remote zu drücken.

Dann lief ich folgendes:

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

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

Schließlich haben wir beschlossen, dass jeder Entwickler seine Git-Konfiguration ändern sollte, um zu verhindern, dass dies jemals wieder passiert:

# Local Git configuration
git config core.ignorecase = true

oder

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

Ich hatte auch gerade das gleiche Problem. In meinem Fall habe ich das Repository geklont und einige Dateien fehlten sofort.

Dies wurde dadurch verursacht, dass der Pfad zur Datei und der Dateiname für Windows zu lang waren. Um dies zu beheben, klonen Sie das Repository so nahe wie möglich am Festplattenstamm, um die Länge des Pfads zur Datei zu verringern. Klonen Sie es beispielsweise auf C:\A\GitRepostatt C:\Users Documents\yyy\Desktop\GitRepo.

Bearbeiten Sie die Datei mit dem Namen .git/config:

sudo gedit .git/config

Oder:

sudo vim .git/config

Inhalt

[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

Wechseln Sie filemode=truein filemode = false.

Bei neuen Versionen von macOS kann dies durch eine Sicherheitsfunktion des Betriebssystems verursacht werden.

In dem Repository, an dem ich gearbeitet habe, gab es eine Binärdatei mit dem Dateityp * .app.

Es waren nur einige serialisierte Daten, aber macOS behandelt alle * .app-Dateien als Anwendung. Da diese Datei nicht vom Benutzer heruntergeladen wurde, hielt das System sie für unsicher und fügte das com.apple.quarantineDateiattribut hinzu , das sicherstellt, dass die Datei nicht ausgeführt werden kann.

Durch das Festlegen dieses Attributs für die Datei wurde jedoch auch die Datei geändert, und es wurde daher im Git-Änderungssatz angezeigt, ohne dass eine Möglichkeit zum Zurücksetzen besteht.

Sie können überprüfen, ob Sie das gleiche Problem haben, indem Sie ausführen $ xattr file.app.

Die Lösung ist ziemlich einfach, solange Sie nicht mit der Datei arbeiten müssen. Fügen *.app binarySie einfach zu Ihrem .gitattributes.

Ich habe mein lokales Repository in einen anderen Ordner kopiert und eine Reihe geänderter Dateien angezeigt. Meine Problemumgehung war: Ich habe die geänderten Dateien gespeichert und den Speicher gelöscht . Das Repository wurde sauber.

Ich habe festgestellt, dass Git meine Dateien (in diesem Fall .psd) als Text behandelt. Das Setzen auf einen Binärtyp in den .gitattributes löste das Problem.

*.psd binary

Ich habe versucht, eine interaktive Rebase durchzuführen, aber es wurde behauptet, dass einige Dateien geändert wurden, sodass ich dies jetzt nicht tun konnte. Ich habe alles versucht , um zu einem sauberen Repository zurückzukehren, aber nichts hat funktioniert. Keine der anderen Antworten half. Aber das hat endlich geklappt ...

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

Boom! Repository reinigen. Problem gelöst. Dann musste ich nur das letzte Commit fallen lassen, als ich mein tat rebase -iund schließlich war alles wieder sauber. Bizarr!

Nur für den Fall, dass es jemand anderem hilft, kann es eine andere Ursache für dieses Problem geben: unterschiedliche Versionen von Git. Ich habe die standardmäßig installierte Version von Git auf einer Ubuntu 18.04 (Bionic Beaver) -Box verwendet und alles hat einwandfrei funktioniert, aber beim Versuch, das Repository mit Git unter Ubuntu 16.04 zu klonen, wurden einige Dateien als geändert angezeigt.

Keine der anderen Antworten hier hat mein Problem behoben, aber das Upgrade der Git-Versionen auf beide Systeme hat das Problem behoben.