SourceTree App sagt nicht festgeschriebene Änderungen sogar für neu geklonte Repositorys – was könnte falsch sein?

Ein Remote-Git-Repository ist nur geklont zu einer lokalen Box mit Atlassian SourceTree. Auch wenn im Worktree keine Dateien wirklich geändert wurden, listet Atlassian gleich eine Reihe von Dateien unter „Uncommitted changes“ auf. Jede Datei zeigt die gleiche Zeilenanzahl sowohl als entfernte als auch als hinzugefügte, und diese Anzahl entspricht der Gesamtanzahl der Zeilen in der Datei. Dies würde irgendwie darauf hindeuten, dass wir auf ein Problem mit dem Zeilenende stoßen.

Allerdings ist das Repository .gitattribute enthält

# Set default behaviour, in case users don't have core.autocrlf set.
* text=auto

das pro GitHub-Artikel Umgang mit Zeilenenden explizit machen sollte core.autocrlf gilt für das Repository. Allerdings auch ~/.gitconfig enthält autocrlf = true.

Wenn versucht wird, die geänderten Dateien auf den vorherigen Commit zurückzusetzen, hat dies keine Auswirkungen. Dieselben Dateien werden immer noch als nicht festgeschrieben angesehen.

Das Repository wurde an mehreren Orten geklont und sichergestellt, dass sich keine Dateien im selben Pfad befinden, um sicherzustellen, dass SourceTree oder Git sich nicht an alte Dateien erinnern.

Das Repository arbeitet mit Windows-, Linux- und OSX-Boxen zusammen. Dieses Problem tritt nur in OSX auf.

Was könnte im SourceTree/Repository/Git-Setup noch falsch sein?

Update Nr. 1, 20. April 2013

Da da noch etwas nicht stimmt, hier Teilausgaben von git config --list.

Von der SourceTree-Konsole (OSX)

core.excludesfile=/Users/User/.gitignore_global
core.autocrlf=input
difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE"
difftool.sourcetree.path=
mergetool.sourcetree.cmd=/Applications/SourceTree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED"
mergetool.sourcetree.trustexitcode=true
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.autocrlf=true

Hier ist die entsprechende Ausgabe von der Windows-Seite:

core.symlinks=false
core.autocrlf=false
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
http.proxy=
core.autocrlf=true
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.eol=native
core.autocrlf=true

Und voll .gitattributes für das betreffende Depot

# Set default behaviour, in case users don't have core.autocrlf set.
* text=auto

*.php    text
*.twig   text
*.js     text
*.html   text diff=html
*.css    text
*.xml    text
*.txt    text
*.sh     text eol=lf
console  text

*.png    binary
*.jpg    binary
*.gif    binary
*.ico    binary
*.xslx   binary

Ich bin einer der SourceTree-Entwickler (ich entwickle eigentlich die Mac-Version des Produkts), also kann ich hoffentlich etwas helfen.

Windows-Rechner wandeln CRLF beim Commit in LF und LF beim Auschecken in CRLF um. autocrlf stellt sicher, dass alles im Repository LF ist. Die Option text = auto ist derjenige, an dem wir jedoch interessiert sind sagt in den Dokumenten:

Wenn Text auf “auto” gesetzt ist, wird der Pfad für die automatische Zeilenende-Normalisierung markiert. Wenn git entscheidet, dass der Inhalt Text ist, werden seine Zeilenenden beim Einchecken auf LF normalisiert.

Sie sehen also beim Einchecken, dass es heißt: “Hey, ich muss diese Zeilenenden normalisieren, weil sie nicht im LF-Format, sondern im CRLF-Format vorliegen.” und modifiziert somit Ihre Arbeitskopie, um die Arbeit zu erledigen, die sie tun soll. Normalerweise müssen Sie unter Mac/Linux nicht normalisieren, da sich alles in LF befindet, aber Git führt eine Überprüfung durch, da Sie möglicherweise aus einem Repository ausgecheckt haben, das zuvor unter Windows entwickelt wurde, oder vielleicht in einem Editor, der CRLF verwendet hat statt LF.

Kurz gesagt, Sie möchten wahrscheinlich alle diese Dateien erneut übertragen, da sie im LF-Format vorliegen sollten, aber stellen Sie auch sicher autocrlf = true (bearbeiten, immer auf wahr!) in Ihrem Windows-Repository, wie es in der Dokumentation steht:

Wenn Sie einfach CRLF-Zeilenenden in Ihrem Arbeitsverzeichnis haben möchten, unabhängig davon, mit welchem ​​Repository Sie arbeiten, können Sie die Konfigurationsvariable “core.autocrlf” setzen, ohne irgendwelche Attribute zu ändern.

Stellen Sie sich jedoch vor, dass das vorherige Zitat beim Einstellen war autocrlf sowohl für ein bestimmtes Repository als auch global.

Hoffentlich hilft dir das weiter, wenn nicht, kannst du gerne weitere Fragen stellen!

Hier ist ein guter SO-Beitrag zu: Zeilenenden: Warum sollte ich core.autocrlf=true in Git verwenden?

BEARBEITEN

Basierend auf der obigen Antwort müssen wir hier einige Dinge sicherstellen.

• Dass Sie die relevanten Git-Optionen in Ihrer eingestellt haben .git/config
• Wenn Sie CRLF-Zeilenenden beibehalten möchten, dann setzen Sie autocrlf=true
• Wenn Sie beim Auschecken Ihres Repositorys nicht möchten, dass Ihre Zeilenenden automatisch konvertiert werden (was dazu führt, dass alle Ihre Dateien sofort den Status “modifiziert” haben), dann setzen Sie die text Option zu unset. Fügen Sie diese Option hinzu, wenn eine globale Git-Konfiguration auf einen Wert eingestellt ist, den Sie nicht möchten.
• Wenn Sie für ein Projekt sowohl auf Windows als auch auf Mac arbeiten, ist es das Beste, was Sie haben text=auto und stellen Sie sicher, dass LF flächendeckend verwendet wird. Deshalb schleichen sich solche Probleme ein; weil Ihre Git-Konfigurationen unterschiedlich sind oder weil das anfängliche Projekt/Git-Setup unter Windows CRLF annimmt, wenn Ihr Mac LF annimmt.

Ich verstehe es immer noch nicht zu 100%, aber für uns war das Problem das * text=auto in dem .gitattribute Datei im Repository. Ich habe nachgesehen, und das haben wir mit Sicherheit core.autocrlf=true an jedem Ort eingestellt, der für meinen Benutzer auf einem Windows-PC eingestellt werden kann. Ich wusste, dass es auch kein SourceTree-Problem war, da TortoiseGit und nur Windows Git (msysgit) alle das gleiche „Problem“ für dieses Repository hatten. Wirklich seltsames Verhalten – ich würde das Repo einmal klonen und sofort 11 “verschiedene” Dateien sehen, dann würde ich löschen und neu beginnen und der nächste Klon hätte 14 “verschiedene” Dateien.

Auskommentieren der * text=auto in dem .gitattribute Datei des Repositorys hat alles behoben. Es ist fast wie text=auto verhält sich nicht so wie autocrlf=true und letzteres ist deaktiviert, wenn das erste in gesetzt ist .gitattribute Datei. Aber das ist nicht das, was jeder Online-Leitfaden anzugeben scheint.

Ich habe die beiden folgenden Zeilen zur Konfigurationsdatei hinzugefügt. Das andere, was ich getan habe, war, auf das Kontrollkästchen “Staged Files” zu klicken und es dann zu deaktivieren, und alles wurde von selbst aktualisiert. Viel Glück.

text = auto 
autocrlf = true

Bin gerade auf dieses Problem gestoßen. Ein frischer Klon zog mehrere Dateien, die nicht nur nicht festgeschrieben waren, sondern auch viele Zeilen echten neuen Codes enthielten. git reflog zeigte nichts, es war kein tatsächlicher Commit, also kam ein getrennter HEAD nicht in Frage.

Nach etwa einer Stunde Recherche fanden wir die Ursache. Einer unserer *nix-Entwickler hatte höchstwahrscheinlich versehentlich Dateien zu einem Ordner hinzugefügt, der den gleichen Namen hatte wie der beabsichtigte, aber eine andere Großschreibung hatte. *nix-Umgebungen konnten diesen neuen Ordner problemlos handhaben, aber Windows (aufgrund der Groß-/Kleinschreibung) hat die beiden Ordner zusammengeführt.

Wenn Sie also beispielsweise zwei Ordner haben, test und Test, in denen sich jeweils eine file.txt befindet und diese beiden file.txt-Dateien nicht identisch sind, kopiert/ersetzt Windows tatsächlich eine davon (nicht sicher, in welcher Reihenfolge). klont Ordner hinein), wodurch die Datei “verändert” und nicht festgeschriebene Änderungen an “Test/file.txt” direkt nach einer Neuinstallation erstellt werden.

Beispiel:

test/
--file.txt (with contents of "This is a commit")

Test/
--file.txt (with contents of "This is a commit with some changes")

Dadurch werden immer neue nicht festgeschriebene Änderungen angezeigt, die aus dem Hinzufügen der Wörter „mit einigen Änderungen“ zu Test/file.txt bestehen, wenn auf einem Windows-Computer geklont wird, während * nix-basierte Computer kein Problem haben.

Dies spricht nicht unbedingt das Problem des OP an, sondern bezieht sich direkt auf die Frage im Titel. Hoffentlich hilft das jemandem da draußen.

Normalerweise ist diese Zeile in .gitattribute:

* text=auto

stellt automatisch sicher, dass alle Dateien, die Git als Text betrachtet, normalisierte (LF) Zeilenenden im Repository haben, selbst wenn git config core.autocrlf ist eingestellt auf false (Ursprünglich). Daher ändert Git die Dateien automatisch nach diesen Regeln.

Sie haben also folgende Möglichkeiten:

• gehen Sie davon aus, dass die Normalisierungsänderungen korrekt sind (soweit sie an den Textdateien vorgenommen wurden) und übertragen Sie sie einfach, z

  $ git diff
  $ git commit -m "Introduce end-of-line normalization" -a
  

• entfernen/deaktivieren Sie die automatische Normalisierung aus der .gitattribute Datei und setzen Sie die Dateien zurück,

• Entfernen Sie den Index und scannen Sie die Dateien erneut, z

  $ rm -v .git/index # Or: git rm --cached -r .
  $ git reset --hard # Rewrite the Git index. Or: git add -u
  

• alternativ, was auch immer Sie tun, versuchen Sie es mit Gewalt (-f), z.B git pull origin -f, git checkout master -fetc.,
• benutzen git Befehlszeile, da dies ein Problem mit der SourceTree-App selbst sein könnte.

Sehen: Umgang mit Zeilenenden bei GitHub docs.