it-swarm.com.de

Unstaged Änderungen nach git reset --hard übrig

Der Titel sagt alles.

Nach git reset --hard gibt mir git status Dateien im Abschnitt Changes not staged for commit:.

Ich habe auch git reset ., git checkout -- . und git checkout-index -f -a versucht, ohne Erfolg.

Wie kann ich diese nicht inszenierten Änderungen loswerden?

Dies scheint nur Visual Studio-Projektdateien zu treffen. Seltsam. Siehe diese Paste: http://Pastebin.com/eFZwPn9Z . Das Besondere an diesen Dateien ist, dass ich in .gitattributes Folgendes habe:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

Außerdem ist autocrlf in meinem globalen .gitconfig auf false gesetzt. Könnte das irgendwie relevant sein?

209
Norswap

Okay, ich habe das Problem irgendwie gelöst.

Es schien, dass die .gitattributes-Datei Folgendes enthielt:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

machte die Projektdateien als unstaged dargestellt. Ich weiß nicht, warum das so ist, und ich hoffe wirklich, dass jemand, der sich mit den Wegen des Idioten auskennt, eine nette Erklärung gibt.

Meine Lösung bestand darin, diese Dateien zu entfernen und autocrlf = false unter [core] in .git/config hinzuzufügen.

Dies entspricht nicht genau der vorherigen Konfiguration, da jeder Entwickler autocrlf = false benötigt. Ich würde gerne eine bessere Lösung finden.

BEARBEITEN:

Ich kommentierte die belastenden Zeilen, machte sie unkommentiert und es funktionierte. Was zum ... ich nicht mal ...!

30
Norswap

Ich hatte das gleiche Problem und es stand im Zusammenhang mit der .gitattributes-Datei ..__ Der Dateityp, der das Problem verursacht hat, wurde jedoch nicht in .gitattributes angegeben.

Ich konnte das Problem lösen, indem ich einfach lief

git rm .gitattributes
git add -A
git reset --hard
312
GameScripting

Git setzt keine Dateien zurück, die sich nicht im Repository befinden. Also kannst du:

$ git add .
$ git reset --hard

Dadurch werden alle Änderungen bereitgestellt, wodurch Git diese Dateien erkennt und diese dann zurücksetzt.

Wenn dies nicht funktioniert, können Sie versuchen, Ihre Änderungen zu verwerfen und zu löschen:

$ git stash
$ git stash drop
82
YuriAlbuquerque

AUFGELÖST!!!

Ich habe dieses Problem mit folgenden Schritten gelöst

1) Entfernen Sie alle Dateien aus Gits Index.

git rm --cached -r .

2) Schreiben Sie den Git-Index neu, um alle neuen Zeilenenden zu erfassen.

git reset --hard

Die Lösung war Teil der auf git site beschriebenen Schritte https://help.github.com/articles/dealing-with-line-endings/

72
Jacek Szybisz

Wenn Sie Git für Windows verwenden, liegt dies wahrscheinlich an Ihrem Problem

Ich hatte das gleiche Problem und Versteck, hartes Zurücksetzen, Säubern, oder sogar alle hinterließen Änderungen. Was sich als Problem herausstellte, war der x-Dateimodus, der von git nicht richtig eingestellt wurde. Dies ist ein "bekanntes Problem" mit Git für Windows. Die lokalen Änderungen werden im Gitk- und Git-Status als alter Modus 100755, neuer Modus 100644, ohne tatsächliche Dateiunterschiede angezeigt. 

Das Update besteht darin, den Dateimodus zu ignorieren:

git config core.filemode false

Mehr Infos hier

45
vezenkov

Mögliche Ursache # 1 - Normalisierung der Leitungsenden

Dies kann beispielsweise dann der Fall sein, wenn die betreffende Datei in das Repository eingecheckt wurde, ohne dass die korrekte Konfiguration der Zeilenenden (1) zu einer Datei im Repository führte, die entweder die falschen Zeilenenden oder gemischte Zeilenenden aufweist. Stellen Sie zur Bestätigung sicher, dass git diff nur Änderungen der Zeilenenden anzeigt (diese sind möglicherweise standardmäßig nicht sichtbar. Versuchen Sie git diff | cat -v, um Wagenrückläufe als Literal ^M-Zeichen anzuzeigen).

Anschließend hat wahrscheinlich jemand einen .gitattributes hinzugefügt oder die Einstellung core.autocrlf geändert, um die Zeilenenden zu normalisieren (2). Basierend auf der .gitattributes- oder der globalen Konfiguration hat Git lokale Änderungen an Ihrer Arbeitskopie vorgenommen, um die angeforderte Zeilenend-Normalisierung anzuwenden. Leider macht git reset --hard diese Änderungen der Liniennormalisierung nicht rückgängig.

Lösung

Problemumgehungen, in denen die lokalen Leitungsenden zurückgesetzt werden, lösen das Problem nicht. Jedes Mal, wenn die Datei von git "gesehen" wird, versucht sie, die Normalisierung erneut anzuwenden, was zu demselben Problem führt.

Die beste Option ist, git die gewünschte Normalisierung anwenden zu lassen, indem alle Zeilenenden im Repo so angepasst werden, dass sie mit dem .gitattributes übereinstimmen, und diese Änderungen übernehmen - siehe Versucht, Zeilenenden mit git filter-branch zu fixieren, jedoch mit kein Glück .

Wenn Sie wirklich versuchen möchten, die Änderungen an der Datei manuell wiederherzustellen, scheint es die einfachste Lösung zu sein, die geänderten Dateien zu löschen und git dann mitzuteilen, dass sie wiederhergestellt werden sollen die Zeit (WARNING: DO NOT führe dies aus, wenn deine modifizierten Dateien andere Änderungen als Zeilenenden haben !!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

Beachten Sie, dass dieses Problem weiterhin auftritt, wenn Sie nicht die Zeilenenden im Repository zu einem bestimmten Zeitpunkt normalisieren.

Mögliche Ursache # 2 - Unempfindlichkeit gegen den Fall

Die zweite mögliche Ursache ist die Unterscheidung zwischen Groß- und Kleinschreibung unter Windows oder Mac OS/X. Angenommen, ein Pfad wie der folgende ist im Repository vorhanden:

/foo/bar

Nun schreibt jemand unter Linux Dateien in /foo/Bar (wahrscheinlich aufgrund eines Build-Tools oder eines Objekts, das dieses Verzeichnis erstellt hat) und pusht. Unter Linux sind dies jetzt zwei separate Verzeichnisse:

/foo/bar/fileA
/foo/Bar/fileA

Wenn Sie dieses Repo unter Windows oder Mac auschecken, kann dies dazu führen, dass fileA nicht geändert werden kann, da git unter Windows bei jedem Reset /foo/bar/fileA auscheckt. Da Windows die Groß- und Kleinschreibung nicht berücksichtigt, wird der Inhalt von fileA mit /foo/Bar/fileA überschrieben "geändert".

Ein anderer Fall kann eine einzelne (n) Datei (en) sein, die im Repo vorhanden ist und sich beim Auschecken in einem Dateisystem ohne Berücksichtigung der Groß-/Kleinschreibung überschneiden würde. Zum Beispiel:

/foo/bar/fileA
/foo/bar/filea

Möglicherweise gibt es andere ähnliche Situationen, die solche Probleme verursachen können.

git on case insensitive Dateisysteme sollten diese Situation wirklich erkennen und eine nützliche Warnmeldung anzeigen, dies ist jedoch derzeit nicht der Fall (dies kann sich in der Zukunft ändern - siehe diese Diskussion und die vorgeschlagenen Patches auf der git.git-Mailingliste) .

Lösung

Die Lösung besteht darin, den Fall von Dateien im Git-Index und den Fall auf dem Windows-Dateisystem in Einklang zu bringen. Dies kann entweder unter Linux durchgeführt werden, was den wahren Zustand der Dinge anzeigt, OR unter Windows mit einem sehr nützlichen Open-Source-Dienstprogramm Git-Unite . Git-Unite wendet die erforderlichen Falländerungen auf den git-Index an, die dann an das Repo übergeben werden können.

(1) Dies war höchstwahrscheinlich eine Person, die Windows verwendet, ohne .gitattributes-Definition für die betreffende Datei und die globale Standardeinstellung für core.autocrlf, nämlich false (siehe (2)).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

14
Raman

Ein weiterer Grund dafür könnten Groß-/Kleinschreibung nicht sein Dateisysteme. Wenn sich in Ihrem Repo mehrere Ordner auf derselben Ebene befinden, deren Namen sich nur von Fall zu Fall unterscheiden, werden Sie davon betroffen. Durchsuchen Sie das Quell-Repository mithilfe seiner Webschnittstelle (z. B. GitHub oder VSTS), um sicherzustellen, dass dies möglich ist. 

Weitere Informationen: https://stackoverflow.com/a/2016426/67824

8
Ohad Schneider

Überprüfen Sie Ihren .gitattributes.

In meinem Fall habe ich *.js text eol=lf darin und git Option core.autocrlf war true

Es bringt mich zu der Situation, wenn git meine Dateileitungen automatisch konvertiert und mich daran hindert, es zu reparieren, und sogar git reset --hard HEAD hat nichts getan.

Ich korrigiere es mit dem Kommentar von *.js text eol=lf in meinem .gitattributes und entkommentierte es danach.

Sieht aus wie es nur Gag Magie.

4
Ohar

Führen Sie clean command aus:

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd
4
mrks

Wenn andere Antworten nicht funktionieren, versuchen Sie, die Dateien hinzuzufügen und dann zurückzusetzen

$ git add -A
$ git reset --hard

In meinem Fall half das, wenn es eine Menge leerer Dateien gab, die von git verfolgt wurden.

4
joshuakcockrell

Keine dieser Methoden funktionierte für mich, die einzige Lösung bestand darin, das gesamte Repo zu nuken und neu zu klonen. Dazu gehören das Ablegen, Zurücksetzen, Hinzufügen und Zurücksetzen, die Clrf-Einstellungen, die Groß-/Kleinschreibung usw.

3
John Hunt

Sie können stash Ihre Änderungen entfernen und dann den Speicher löschen:

git stash
git stash drop
3
Shahbaz

Ich traf ein ähnliches Problem mit .gitattributes, aber für meinen Fall betraf GitHubs LFS. Dies ist zwar nicht genau das Szenario des OPs, aber ich denke, es bietet die Möglichkeit, zu veranschaulichen, was die .gitattributes-Datei macht und warum sie zu nicht-inszenierten Änderungen in Form von "Phantom" -Unterschieden führen kann.

In meinem Fall befand sich bereits seit Beginn der Zeit eine Datei in meinem Repository. Bei einem kürzlich erfolgten Commit habe ich eine neue git-lfs track-Regel mit einem Muster hinzugefügt, das im Nachhinein etwas zu breit war, und am Ende mit dieser alten Datei übereinstimmte. Ich weiß, dass ich diese Datei nicht ändern wollte. Ich weiß, dass ich die Datei nicht geändert habe, aber jetzt befanden sich diese Änderungen in meinen nicht bereitgestellten Änderungen, und es wurde keine Menge von Überprüfungen oder harten Zurücksetzungen in dieser Datei behoben. Warum?

Die GitHub LFS-Erweiterung arbeitet hauptsächlich durch die Nutzung der Hooks, die git den Zugriff über die .gitattributes-Datei ermöglicht. Im Allgemeinen geben die Einträge in .gitattributes an, wie übereinstimmende Dateien verarbeitet werden sollen. Im Fall des OP ging es um die Normalisierung von Zeilenenden. Bei mir ging es darum, ob LFS die Dateispeicherung übernehmen sollte. In beiden Fällen stimmt die tatsächliche Datei, die git beim Berechnen eines git diffs sieht, nicht mit der Datei überein, die Sie beim Überprüfen der Datei sehen. Wenn Sie also ändern, wie eine Datei über das entsprechende .gitattributes-Muster verarbeitet wird, wird sie im Statusbericht als nicht gespeicherte Änderungen angezeigt, auch wenn die Datei wirklich nicht geändert wird.

Alles was gesagt wurde, meine "Antwort" auf die Frage ist, dass, wenn die Änderung in der .gitattributes-Datei etwas ist, das Sie tun wollten, Sie eigentlich nur die Änderungen hinzufügen und fortfahren sollten. Wenn nicht, ändern Sie den .gitattributes, um besser darzustellen, was Sie tun möchten.

Verweise

  1. GitHub LFS-Spezifikation - Große Beschreibung, wie sie sich in die Funktionsaufrufe clean und smudge einhaken, um Ihre Datei in den git-Objekten durch eine einfache Textdatei mit einem Hash zu ersetzen.

  2. gitattributes Documentation - Alle Informationen darüber, was verfügbar ist, um anzupassen, wie git Ihre Dokumente verarbeitet.

1
merv

Ich glaube, es gibt ein Problem mit git für Windows, bei dem git zufällig die falschen Zeilenenden an der Kasse schreibt. Die einzige Problemumgehung besteht darin, einen anderen Zweig zu überprüfen und git zu zwingen, Änderungen zu ignorieren. Dann checken Sie den Zweig aus, an dem Sie tatsächlich arbeiten möchten.

git checkout master -f
git checkout <your branch>

Beachten Sie, dass dadurch eventuell beabsichtigte Änderungen verworfen werden. Machen Sie dies nur, wenn Sie dieses Problem direkt nach dem Auschecken haben.

Edit: Ich habe beim ersten Mal tatsächlich Glück gehabt. Es stellt sich heraus, dass ich nach dem Wechseln der Zweige wieder etwas gebissen habe. Es stellte sich heraus, dass die Dateien von git als geändert gemeldet wurden, nachdem sich die Zweige geändert hatten. (Anscheinend, weil git die CRLF-Zeile nicht ordnungsgemäß auf Dateien angewendet hat.)

Ich habe das neueste git für Windows aktualisiert und hoffe, das Problem ist verschwunden.

0
mrfelis

Wie andere Antworten gezeigt haben, liegt das Problem an der automatischen Korrektur des Zeilenendes. Dieses Problem ist bei * .svg-Dateien aufgetreten. Ich habe die svg-Datei für die Symbole in meinem Projekt verwendet. 

Um dieses Problem zu lösen, lasse ich git wissen, dass svg-Dateien als binär statt als Text behandelt werden sollten, indem die folgende Zeile zu .gitattributes hinzugefügt wird

* .svg binär

0
vuamitom

Ich hatte das gleiche Problem. Ich habe git reset --hard HEAD gemacht, aber immer noch jedes Mal, wenn ich git status tat, sah ich einige Dateien als geändert.

Meine Lösung war relativ einfach. Ich habe gerade meine IDE (hier war Xcode) geschlossen und meine Befehlszeile geschlossen (hier war es auf meinem Mac OS Terminal) und habe es erneut versucht und es hat funktioniert.

Ich konnte jedoch nie herausfinden, woher das Problem kam.

0
Honey

Ähnliches Problem, obwohl ich sicher nur an der Oberfläche bin. Auf jeden Fall kann es jemandem helfen: Was ich getan habe (FWIW, in SourceTree): Die nicht festgeschriebene Datei wurde abgelegt, dann ein Hard-Reset ausgeführt. 

0
elder elder

Eine andere Möglichkeit, der ich begegnete, war, dass eines der Pakete im Repository mit einem separaten HEAD endete. Wenn keine der Antworten hier hilfreich ist und Sie auf eine solche Statusmeldung stoßen, haben Sie möglicherweise dasselbe Problem:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   path/to/package (new commits)

Wenn Sie in den path/to/package-Ordner gehen, sollte ein git status folgendes Ergebnis ergeben:

HEAD detached at 7515f05

Der folgende Befehl sollte dann das Problem beheben, wobei master durch Ihren lokalen Zweig ersetzt werden sollte:

git checkout master

Und Sie erhalten eine Nachricht, dass Ihre lokale Niederlassung einige Commits hinter der entfernten Niederlassung hat. git pull und du solltest aus dem Wald sein!

0

In einer ähnlichen Situation. Infolge jahrelanger Qualen mit vielen Programmierern, die in der Lage waren, verschiedene Kodierungen der Zeilenenden (.asp, .js, .css ... nicht die Essenz) in eine Datei zu packen. Vor einiger Zeit lehnte .gitattributes ab. Einstellungen für Repo links autorclf = true undsafecrlf = warn.

Das letzte Problem trat beim Synchronisieren aus dem Archiv mit unterschiedlichen Zeilenenden auf. Nach dem Kopieren aus dem Archiv werden im git-Status viele Dateien mit der Notiz geändert

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Tipps von Wie normalisiert man die Enden von Arbeitsbaumlinien in Git? hat geholfen

git add -u

0
MrSwed