wake-up-neo.com

Dateien werden direkt nach git clone als geändert angezeigt

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

Wenn ich dieses Repository klone, dann cd in das Repo, zeigt git-status mehrere Dateien als geändert an. Hinweis: Ich habe das Repo in keinem Editor geöffnet. 

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

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

Jede Hilfe/Ideen wäre sehr dankbar

Update 1: Ich bin auf einem Mac und das Repo selbst enthält keine Submodule.

Update 2: Das Dateisystem ist das "Journaled HFS +" - Dateisystem auf dem Mac und unterscheidet nicht zwischen Groß- und Kleinschreibung. Die Dateien sind einzeilig und jeweils etwa 79 KB groß (ja, Sie haben es richtig gehört), so dass der Blick auf git diff nicht besonders hilfreich ist. Ich habe gehört, git config --global core.trustctime false zu tun, was helfen könnte, was ich versuchen werde, wenn ich mit dem Repo auf den Computer zurückkomme.

Update 3: veränderte Details des Dateisystems mit Fakten! und ich habe den git config --global core.trustctime false-Trick ausprobiert, der nicht sehr gut funktionierte.

206
Sam Elliott

Ich habe es verstanden. Alle anderen Entwickler sind auf Ubuntu (denke ich) und haben daher Dateisysteme, die die Groß- und Kleinschreibung berücksichtigen. Ich allerdings nicht (da ich auf einem mac bin). Tatsächlich hatten alle Dateien Zwillinge in Kleinbuchstaben, als ich sie mit git ls-tree HEAD <path> betrachtete.

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

84
Sam Elliott

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

Nach dem Ausführen von git config --global core.autocrlf input wurden alle Dateien immer noch als geändert markiert. Nachdem ich nach einem Fix gesucht hatte, stieß ich im Home-Verzeichnis auf .gitattributes-Datei, die Folgendes aufwies.

* text=auto

Ich habe es kommentiert und alle anderen geklonten Repositories funktionieren von nun an gut. Hoffe, das hilft jedem da draußen.

135
adnans
git config core.fileMode false

dieses Problem in meinem Fall gelöst

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

TL; DR;

core.fileMode

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

Der Standardwert ist true, mit der Ausnahme, dass git-clone (1) oder git-init (1) core.fileMode auf "false" prüfen und gegebenenfalls festlegen, wenn das Repository erstellt wird.

57
Piotr Korlaga

Ich gehe davon aus, dass Sie Windows verwenden. Diese GitHub-Seite, auf die Sie verlinkt haben, enthält die Details in umgekehrter Reihenfolge. Das Problem ist, dass CR + LF Zeilenenden bereits in das Repository übernommen wurden und Sie core.autocrlf auf einen der beiden Werte gesetzt haben true oder input , Git möchte die Zeilenenden in LF konvertieren , so zeigt git status, dass jede Datei geändert wird.

Wenn es sich um ein Repository handelt, 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 nur 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 Änderungen vornehmen können. Möglicherweise möchten Sie das Problem beheben, indem Sie ein Commit ausfü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 erneut auftritt in der Zukunft.

Das Folgende stammt direkt aus der gitattributes man page 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, die nicht normalisiert werden sollen, in git status angezeigt werden, deaktivieren Sie deren Textattribut, bevor Sie git add -u ausführen.

manual.pdf      -text

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

weirdchars.txt  text
52
Arrowmaster

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
32
kds

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

* text=auto

Diese Zeile befindet sich am oberen Rand der Datei. Wir mussten nur die Zeile auskommentieren, indem wir ein # vor der Zeile einfügen. Danach funktionierten die Dinge wie erwartet.

15
J Adam Rogers

Das Problem könnte sich auch aus unterschiedlichen Dateiberechtigungen ergeben, 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
   ↑↑↑
11
Gima

Ich hatte das gleiche Problem. Auch mit einem Mac. Beim Betrachten des Repos auf einem Linux-Computer fiel mir auf, dass ich zwei Dateien hatte:

geoip.dat und GeoIP.dat

Das veraltete auf dem Linux-Rechner wurde entfernt und das Repository erneut auf den Mac geklont. Ich war nicht in der Lage, meine Kopie des Repositorys abzurufen, festzulegen, zu speichern oder zu speichern, wenn Duplikate vorhanden waren.

3
user2148301

Ich wollte eine Antwort hinzufügen, die sich mit dem Thema "Warum" befasst, da dies bereits eine gute Antwort gibt.

.gitattributes hat also eine * text=auto-Einstellung, die dieses Problem verursacht.

In meinem Fall hatten Dateien im GitHub-Zweigzweig \r\n-Endungen. Ich habe die Einstellungen des Repos angewählt, um mit \n-Endungen einzuchecken. Ich weiß nicht, was git überprüft. Es sollte mit nativen Endungen auf meine Linux-Box (\n) ausgecheckt werden, aber ich denke, es hat die Datei mit \r\n-Endungen ausgecheckt. Git beschwert sich, weil er die ausgecheckten \r\n-Endungen des Repos sieht und mich warnt, dass er die \n-Einstellungen überprüfen wird. Daher sind Dateien "zu ändern".

Das ist mein Verständnis für den Moment.

3
Dennis

Bearbeiten Sie die Datei mit dem Namen: Sudo gedit .git/configSudo 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

Ändern Sie filemode = true in filemode = false.

1
Pramod Kharade

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

Dies wurde durch den Pfad zu der Datei und den Dateinamen verursacht, der für Windows zu lang ist. Um es aufzulösen, klonen Sie das Repo so nah wie möglich an der Festplatte der Festplatte, um die Länge des Pfads zur Datei zu verringern, z. Klonen Sie es nach C:\A\GitRepo anstelle von C:\Users Documents\yyy\Desktop\GitRepo

1
8bitme

Ich habe mein lokales Repository in einen anderen Ordner kopiert, und es wurden einige geänderte Dateien angezeigt. ... Mein Workaround war: Ich habe die geänderten Dateien gestaut und den Stash gelöscht. Das Repository wurde sauber.

0
Oleg Shvetsov

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-Box (Bionic Beaver) verwendet und alles hat einwandfrei funktioniert. Beim Versuch, das Repository mit Git auf Ubuntu 16.04 zu klonen, wurden einige Dateien als geändert angezeigt.

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

0
Todd Chaffee

Gleiche Ausgabe für mich. Ich konnte mehrere Bilder mit dem gleichen Namen wie "textField.png" und "textfield.png" im Remote-Git-Repo sehen, aber nicht in meinem lokalen Repo. Ich konnte nur "textField.png" sehen, das nicht im Projektcode ..__ Es stellt sich heraus, dass die meisten meiner Kollegen auf Ubuntu mit ext4-Dateisystem arbeiten, während ich auf einem Mac mit APFS bin.

Dank der Antwort von Sam Elliott war die Lösung ziemlich einfach. Zuerst bat ich einen Kollegen auf Ubuntu, die redundanten Dateiversionen mit Großbuchstaben zu löschen, dann Commit und Push on Remote.

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 geschieht

# Local Git config
git config core.ignorecase = true

oder 

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

Ich habe festgestellt, dass git meine Dateien (in diesem Fall .psd) als Text behandelt. Durch das Festlegen eines binären Typs in den .gitattributes wurde das Problem gelöst.

*.psd binary
0
Lanny

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

Im Repository, an dem ich gerade arbeitete, befand sich eine binäre Datei mit dem Dateinamen * .app als Dateityp ..__ Es waren nur einige serialisierte Daten, aber macOS behandelt alle * .app-Dateien als Anwendung, und diese Datei wurde nicht heruntergeladen Vom Benutzer wurde das System als unsicher eingestuft und das com.Apple.quarantine-Dateiattribut hinzugefügt, um sicherzustellen, dass die Datei nicht ausgeführt werden kann.

Das Festlegen dieses Attributs für die Datei hat jedoch auch die Datei geändert und daher im git-Änderungssatz angezeigt, ohne dass sie zurückgesetzt werden konnte.

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

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

0
Lukas Zech

Ich hatte ein ähnliches Problem und fand diese Frage.

Ich habe versucht, eine interaktive Neugestaltung durchzuführen, aber es wurde behauptet, dass es einige modifizierte Dateien gab, also würde ich es jetzt nicht tun. Ich habe ALLES versucht, um zu einem sauberen Repo zurückzukehren, aber nichts hat funktioniert. Keine der anderen Antworten hat geholfen. Aber das hat endlich funktioniert ...

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

Boom! Repo reinigen. Problem gelöst. Dann musste ich nur noch das letzte Commit ablegen, als ich meinen rebase -i tat und endlich war alles wieder sauber .. _. Bizarre!

Aber ich füge diese Lösung hier hinzu, so dass ich vielleicht diesmal sehen und versuchen kann, falls ich wieder auf dieses Thema stoße. Danke: D

0
Thomas Aylott