Git: lokale Änderungen können nicht rückgängig gemacht werden (Fehler: Pfad … ist nicht zusammengeführt)

Ich habe folgenden Arbeitsbaumzustand

$ git status foo/bar.txt
# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       deleted by us:      foo/bar.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Datei foo/bar.txt ist da und ich möchte es wieder in den “unveränderten Zustand” bringen (ähnlich wie ‘svn revert’):

$ git checkout HEAD foo/bar.txt
error: path 'foo/bar.txt' is unmerged
$ git reset HEAD foo/bar.txt
Unstaged changes after reset:
M       foo/bar.txt

Jetzt wird es verwirrend:

$ git status foo/bar.txt
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   foo/bar.txt
#
# 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:   foo/bar.txt
#

Dieselbe Datei in beiden Abschnitten, neu und geändert? Was sollte ich tun?

Du hast es falsch herum gemacht. Sie sollten zuerst zurücksetzen, die Datei aus der Staging-Umgebung entfernen und dann auschecken, um lokale Änderungen rückgängig zu machen.

Versuche dies:

$ git reset foo/bar.txt
$ git checkout foo/bar.txt

Das hat bei mir perfekt funktioniert:

$ git reset -- foo/bar.txt
$ git checkout foo/bar.txt

git checkout origin/[branch] .
git status

// Punkt (.) am Ende beachten. Und alles wird gut

In neueren Git-Versionen git restore soll eine “bessere” Möglichkeit sein, unerwünschte lokale Änderungen rückgängig zu machen, als die überladenen checkout. Großartig, das klingt vernünftig – ein nettes, einfaches, zweckgebundenes Werkzeug für eine allgemeine Operation.

Aber hier ist mein neuer „Lieblings“-Git-Bug. Ja, ich weiß, dass irgendein Idiot sagen wird: “Es ist kein Fehler, es ist beabsichtigt”. Aber bei dieser Art von Benutzeroberfläche bleibe ich beim Spitznamen “Bug”:

% git restore LEGAL
error: path 'LEGAL' is unmerged
# okay, fine...
% git restore --ignore-unmerged LEGAL
warning: path 'LEGAL' is unmerged
# Arg, what?!

(bereitgestellt von git 2.25.1)

Zuerst das kleine Problem: Wenn ein Tool aufgrund einer bestimmten Bedingung etwas verweigert, ist dies nicht nur eine Warnung. Beim am wenigsten es sollte sagen, dass die Operation nicht durchgeführt wurde. Jetzt muss ich nachforschen, ob die Operation tatsächlich durchgeführt wurde oder nicht (Hinweis: war es nicht).

Das zweite Problem ist natürlich offensichtlich. Schauen wir uns nun den Manpage-Eintrag an, um zu sehen, warum dieses fantastische Tool nicht das tut, was ich ihm sage:

   --ignore-unmerged
       When restoring files on the working tree from the index, do not
       abort the operation if there are unmerged entries and neither
       --ours, --theirs, --merge or --conflict is specified. Unmerged
       paths on the working tree are left alone.

Heiliger Rauch! Ich denke, die Git-ish-Lösung für das Problem mit der Benutzeroberfläche hier wird darin bestehen, die Option von umzubenennen --ignore-unmerged zu --ignore-unmerged-except-in-cases-where-we-do-not-want-to-allow-that--consult-documentation-then-source-code-then-team-of-gurus-when-you-cannot-figure-it-out---and-wait-while-half-of-them-argue-about-why-it-is-right-as-is-while-the-other-half-advocate-adding-four-more-options-as-the-fix.

Gehen Sie dann zur Community, um eine Lösung zu finden. Du traust dich ja nicht.

Offensichtlich hatte ich meine Refs nicht in einem Zustand, in dem die baumartigen Blobs mit den Commit-ishes von der Arbeitsdatei zum Staging-Bereich aufgelöst werden konnten … äh Index?

git checkout foo/bar.txt

hast du das probiert? (ohne HEAD-Schlüsselwort)

Normalerweise mache ich meine Änderungen auf diese Weise rückgängig.

ich finde git stash sehr nützlich für die zeitliche Behandlung aller ‘schmutzigen’ Zustände.