Änderungen in Git können scheinbar nicht verworfen werden


124

Nachdem Sie Folgendes über die Befehlszeile gesehen haben:

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

Ich versuche, meine Änderungen durch Eingabe des folgenden Befehls zu verwerfen:

git checkout -- index.htm

Aber wenn ich den Git-Status erneut starte, sieht es genauso aus. Die Kasse scheint nicht zu funktionieren. Mache ich etwas falsch? Ich verwende GIT 1.6.1.2 unter Windows / Cygwin.

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

4
Funktioniert das git checkout HEAD -- index.htmAuschecken aus dem zuletzt festgeschriebenen Status anstelle des Auscheckens aus dem Index?
Jakub Narębski

3
git checkout HEAD -- index.htmhat für mich gearbeitet!
Ben Tideswell

Antworten:


52

Das hat mich schon eine Weile gestört, fast jedes Repo, das ich auscheckte, hatte Änderungen, die ich nicht verwerfen konnte. Lange Rede, kurzer Sinn, ich habe alles versucht, nichts hat funktioniert. Folgendes habe ich getan, um die Dinge wieder normal zu machen (auf einem Mac):

Completely remove the autocrlf & safecrlf settings from ~/.gitconfig
Completely remove the autocrlf & safecrlf settings from your repo's local config ./.git/config
git rm --cached -r .
git reset --hard

7
Nachdem ich alles oben ausprobiert hatte, war dies das einzige, was für mich (unter Windows) funktionierte
Anders

Danke dir! Wie Anders sagte, funktioniert diese Lösung auch für mich. Ich habe autocrlf durch # autocrlf ersetzt
David

37

Hier ist meine Erfahrung, setzen Sie folgende Variablen in .git/config:

[core]
    autocrlf = false
    safecrlf = false
    eol = crlf

dann laufen $ git checkout HEAD ., und es funktioniert. aber $ git checkout -- .nicht seltsam!

* Git Version 1.9.3


35

Welche Änderungen git diffwerden in der Datei angezeigt? Unter Windows habe ich Probleme mit Zeilenenden gesehen, die solche Probleme verursachen. Überprüfen Sie in diesem Fall, welche Einstellungen Sie für git config core.autocrlfund haben git config core.safecrlf. Hier finden Sie eine Dokumentation zu diesen Einstellungen .

Ich würde sagen, wenn Sie git svnfür die Integration mit Subversion verwenden, stellen Sie sicher, dass deaktiviert autocrlfist. Soweit ich weiß, ist es in dieser Konfiguration nur defekt und die meisten Tools glauben, dass Dateien geändert wurden, wenn Sie checkoutÄnderungen vorgenommen haben.

Wenn Sie dort ein Problem sehen git checkoutund dann git statusanzeigen, dass die Datei noch geändert wurde und git diffdie Datei in jeder Zeile der Datei geändert wird, ist dies das Problem, das Sie sehen.

core.autocrlf

Wenn dies der Fall ist, konvertiert git CRLF am Ende von Zeilen in Textdateien beim Lesen aus dem Dateisystem in LF und beim Schreiben in das Dateisystem umgekehrt. Die Variable kann auf Eingabe gesetzt werden. In diesem Fall erfolgt die Konvertierung nur beim Lesen aus dem Dateisystem, Dateien werden jedoch am Ende der Zeilen mit LF ausgeschrieben. Derzeit wird ausschließlich anhand des Inhalts entschieden, welche Pfade als "Text" zu betrachten sind (dh dem Autocrlf-Mechanismus zu unterwerfen sind).

core.safecrlf

Wenn true, wird git überprüft, ob die Konvertierung von CRLF, wie von core.autocrlf gesteuert, reversibel ist. Git überprüft, ob ein Befehl eine Datei im Arbeitsbaum direkt oder indirekt ändert. Wenn Sie beispielsweise eine Datei festschreiben und anschließend dieselbe Datei auschecken, erhalten Sie die Originaldatei im Arbeitsbaum. Wenn dies bei der aktuellen Einstellung von core.autocrlf nicht der Fall ist, lehnt git die Datei ab. Die Variable kann auf "warn" gesetzt werden. In diesem Fall warnt git nur vor einer irreversiblen Konvertierung, setzt aber den Vorgang fort. ...


core.autocrlf = true core.safecrlf wurde nicht gesetzt. Sollte dies für Windows auf true gesetzt werden? Was ist der Unterschied zwischen den beiden?

Ich würde sagen, lassen Sie beide aus, wenn Sie git svn verwenden. Ich habe einige Details hinzugefügt.
1800 INFORMATION

4
Ich gehe davon aus, dass er es um mindestens 90 Grad
drehen will

2
Wenn ich sowohl core.autocrlf als auch core.safecrlf auf true gesetzt habe, konnte ich erkannte Änderungen in den fehlerhaften Dateien verwerfen, indem ich 'git reset --hard HEAD' ausführte.
Aleksey

18

Ich denke du musst bestehen -f

Aus der Manpage ( man git-checkout, GIT-CHECKOUT (1)):

-f, --force Fahren Sie fort,
auch wenn sich der Index oder der Arbeitsbaum von HEAD unterscheidet.
Dies wird verwendet, um lokale Änderungen wegzuwerfen .

Verwerfen Sie beispielsweise Änderungen am aktuellen Zweig und wechseln Sie zu einem anderen Zweig:

git checkout -f master

7
Pass -f an was? Wäre schön, die Antwort zu vervollständigen
PandaWood

@Matt meine Absicht war es nicht, einen anderen Zweig auszuchecken. Die Antwort stammt aus dem Jahr 2009, daher erinnere ich mich nicht wirklich, aber nach der Frage zu urteilen, denke ich, ich wollte -fzur Kasse gehen - <Dateiname> wie ingit checkout -f -- filename
hasen

@hasen Die drei Kommentare, die Sie hatten, haben um Klarstellung gebeten, weshalb ich das "zum Beispiel" hinzugefügt habe. Das Beispiel schließt andere Verwendungen von-f
Matt H

Hat für mich gearbeitet. git checkout -f masterwarf "Bereits auf 'Master'", aber die Änderungen waren weg.
Christian

11

Es kann sich um Zeilenenden handeln, wie aus @ 1800-Informationen hervorgeht, aber eine andere Möglichkeit besteht darin, dass der Unterschied (der verhindert, dass Sie diese Dateien mit einem Checkout-Befehl zurücksetzen) im Dateimodus liegt. Das ist mir passiert. Auf meiner Version von git können Sie dies mithilfe von entdecken

git diff index.htm

Und es zeigt Ihnen Änderungen im Dateimodus. Sie können sie jedoch auch mit der Option -f beim Auschecken nicht zurücksetzen. Verwenden Sie dazu entweder

git config core.filemode false

oder ändern Sie Ihre git .config in Ihrem Texteditor durch Hinzufügen

[Ader]

filemode = false

Nachdem Sie dies getan haben, können Sie verwenden

git reset HEAD index.htm

und die Datei sollte verschwinden.

(Ich habe all dies aus den Antworten auf Wie kann ich Änderungen am Git-Ignoriermodus (chmod) vornehmen und die Dateiberechtigungen nur in Git aktualisieren ? )


6

Sind Sie unter OSX oder Windows? In diesem Fall liegt das Problem wahrscheinlich darin, dass zwei Dateien mit demselben Namen und unterschiedlicher Groß- und Kleinschreibung vorhanden sind. z.B. index.htm und Index.htm

Windows und standardmäßig OSX verwenden ein Dateisystem, bei dem die Groß- und Kleinschreibung nicht berücksichtigt wird. Dies steht in Konflikt mit dem Git, bei dem die Groß- und Kleinschreibung beachtet wird.


2

Ich hatte dieses Problem und nachdem ich all das ausprobiert hatte, funktionierte nichts.

Was für mich funktioniert hat, war, das Verzeichnis zu löschen, in dem sich die Datei befand, git statusund dann sicherzustellen, dass alle Dateien in diesem Verzeichnis jetzt als gelöscht markiert sind. Danach habe ich es einfach gemacht git checkout -fund alles war wieder normal.


1

Ich habe an einem libGDXProjekt gearbeitet Android Studiound wollte alle Änderungen verwerfen, die ich vorgenommen habe, und nichts hat für mich funktioniert. Die Lösung, die ich gefunden habe, bestand darin, alle Änderungen in einen neuen Zweig zu übernehmen

git checkout -b TRASH
git add .
git commit -m "discarded changes"
git checkout master

und dann können Sie den TRASHZweig löschen, wenn Sie möchten.


1

Ich hatte das gleiche Problem, nichts aus den obigen Kommentaren hat funktioniert. Es stellte sich heraus, dass mein Dateisystem nicht zwischen Groß- und Kleinschreibung unterscheidet (OSX-Standard, aber Windows verhält sich wahrscheinlich gleich) und eine Datei mit Groß- und Kleinbuchstaben im selben Verzeichnis mit unterschiedlichem Inhalt vorhanden war. Da auf meinem Computer beide Namen auf dieselbe Datei zeigten, zeigte der Git-Status immer eine Änderung, egal was ich tat. So beheben Sie das Problem:

  • Ich musste eine der Dateien von einem anderen Computer entfernen und zum Repo verschieben

  • Löschen Sie die gesamte lokale Version vollständig

  • Git-Klon von Grund auf neu


0

Ich hatte ein ähnliches Problem, bei dem ich keine Dateien verwerfen konnte, die entweder nicht vorhanden sind oder geändert wurden. Ich verwende Visual Studio bei der Arbeit und habe festgestellt, dass dies passiert, wenn Zweige gewechselt werden, während die App ausgeführt wird.

git checkoutund der Versuch, wegzuwerfen, half nicht. Es würde nicht funktionieren oder es würde mir nur sagen, dass ich keine Erlaubnis habe.

Lösung, die funktioniert hat:

  1. Wechseln Sie in den abgesicherten Modus
  2. Dateien verwerfen

Ein Neustart ist ein Schmerz, aber dies funktionierte schneller als das Ausprobieren von 100 Dingen.


0

Es gibt eine einfache Lösung. Wenn dies passiert (normalerweise durch unerwartetes Herunterfahren von Windows oder Speicherauszug) und Sie Ihre Änderungen nicht verwerfen und sogar zwischen Zweigen wechseln können (Git sagt, Sie haben nicht genügend Berechtigungen); in der WindowsUmgebung show all hidden files and foldersaus Ordneroptionen. Gehen Sie in Ihr GIT-Verzeichnis (sollte mit beginnen .git) und löschen Sie die "index.lock"Datei. Dann sollte Git Sie tun lassen, was Sie wollen.


0

Am Ende machte ich ein git stashgefolgt von einem git stash clean, um einige loszuwerden. In .git / oder ~ / .git wurden keine automatischen cr / lf-Konfigurationen angezeigt.


0

In meinem Fall konnte ich Änderungen an einem Verzeichnis nicht verwerfen. zB wenn ich einen Git Diff laufen ließ, würde ich das sehen: -Subproject commit fdcccccccccccccccccccccccccccccccccccccc +Subproject commit f1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

Also habe ich dieses Verzeichnis aufgerufen und dort einen Git-Status ausgeführt. Es war in einem KOPF losgelösten Zustand. Und dann bin ich einfach reingelaufen git checkout master. Das hat die Dinge für mich richtig gemacht. Dies ist jedoch nicht hilfreich für das genaue Szenario, das hier gefragt wird.


0

Dies ist eine alte Frage, die mir aber immer noch relevant war. Ich fand meine Antwort erst, als ich mich im Büro erkundigte, und stellte fest, dass das Problem bei Submodulen lag. Wenn sie aktualisiert werden und Ihr eigenes Repository diese Änderungen nicht widerspiegelt, werden Unterschiede angezeigt. Das Zurücksetzen des Kopfes hilft nicht. Wenn dies der Fall ist, führen Sie Folgendes aus:

git status update

Das sollte helfen, Dinge zu reparieren (in diesem speziellen Fall)


0

Ich hatte ein Berechtigungsproblem in Windows und musste icacls containingFolder /reset /t /l /cden Ordner doppelklicken, um meine Berechtigungen zurückzugewinnen.


0

Ich hatte .gitattributes mit folgendem Inhalt:

* text=auto eol=lf

Um das Problem zu beheben, bearbeiten Sie .gitattributesdiese Zeile, um die Zeilenenden zu entfernen. Dann git reset --hard HEADdie Dateien und die .gitattributesDatei zurückgesetzt.


0

Für mich war dieses Problem eine Kombination aus dem Herunterladen eines Git-LFS-Images, das über Netlify CMS hochgeladen und von ihrem Netlify Large Media-Handler anders bereitgestellt wurde.

Meine Lösung bestand darin, diese Zeilen ~/.gitconfigso zu kommentieren / zu entfernen , dass sie wie unten aussehen, und sie dann git statuserneut zu überprüfen .

# [filter "lfs"]
#   clean = git-lfs clean %f
#   smudge = git-lfs smudge %f
#   required = true

ODER Sie können wahrscheinlich einen .gitconfiglokaleren Filter über a im Repo-Stammverzeichnis hinzufügen und die Filterregeln für lfs dort irgendwie überschreiben.

Hoffe das hilft einem Kerl raus.


-1

Ich hatte auch ein ähnliches Problem und die folgenden Schritte haben mir geholfen:

git commit -am 'temp commit'
git pull origin master
git reset head~1
git reset head --hard

Hoffe, es hilft auch anderen Menschen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.