Git: can't undo local changes (error: path ... is unmerged)
Solution 1
You did it the wrong way around. You are meant to reset first, to unstage the file, then checkout, to revert local changes.
Try this:
$ git reset foo/bar.txt
$ git checkout foo/bar.txt
Solution 2
This worked perfectly for me:
$ git reset -- foo/bar.txt
$ git checkout foo/bar.txt
Solution 3
git checkout origin/[branch] .
git status
// Note dot (.) at the end. And all will be good
Solution 4
In recent git versions, git restore
is supposed to be a "better" way to revert undesired local changes than the overloaded checkout
. Great, that sounds reasonable - a nice simple purpose-built tool for a common operation.
But, here's my new "favorite" git bug. Yes, I know some git-head is going to say, "It's not a bug, it's by design". But with this kind of user interface, I stand by the "bug" moniker:
% git restore LEGAL
error: path 'LEGAL' is unmerged
# okay, fine...
% git restore --ignore-unmerged LEGAL
warning: path 'LEGAL' is unmerged
# Arg, what?!
(brought to you by git 2.25.1)
First the minor issue: when a tool refuses to do something because of a particular condition, it's not just a warning. At least it should say the operation was not performed. Now I have to go investigate whether the operation was actually performed or not (hint: it wasn't).
The second issue, of course, is obvious. Now, let's look at the man page entry to see why this fantastic tool won't do what I am telling it to do:
--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.
Holy smokes! I guess the git-ish fix for the user interface problem here will be to rename the option from --ignore-unmerged
to --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
.
Then go to the community to find out a fix. I dare you.
Obviously, I didn't have my refs in a state where the tree-ish blobs could be resolved with the commit-ishes from working file to staging area... err index?
mklhmnn
Updated on July 08, 2022Comments
-
mklhmnn almost 2 years
I have following working tree state
$ 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")
File
foo/bar.txt
is there and I want to get it to the "unchanged state" again (similar to '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
Now it is getting confusing:
$ 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 #
The same file in both sections, new and modified? What should I do?