Git: can't undo local changes (error: path ... is unmerged)

git git-checkout git-reset

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?

I wish someone could explain how do we get into this situation, why it happens, and why the solution works.

I got into this situation when I popped my stash after a rebase which got me into a merge conflict (stash pop does a merge)....To resolve it, i did a "checkout --theirs" ....apparently my changes were still there....to remove those..I tried a checkout on the file again..that's when I saw the above error.

Igor Zevaka

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

Thanks; worked like a charm! I had to commit (not with the -a arg, the relevant changes were already staged) and then I was able to push/pull like normal.

For me it required a:
$ git reset -- foo/bar.txt
$ git checkout -- foo/bar.txt
(Notice the extra "--" in between)

The good syntax is "git reset HEAD file1 file2 ..." then "git checkout -- file1 file2..."

It's always amusing when the highest voted answer basically just says "you're doing it wrong" :)

An explanation (on what things do) would have been great …

fedorqui

This worked perfectly for me:

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

Joe Hyde

git checkout origin/[branch] .
git status

// Note dot (.) at the end. And all will be good

Juan

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?

Bruno Cunha

If the above answers didn't work try:

git reset -–merge

zed_0xff

git checkout foo/bar.txt

did you tried that? (without a HEAD keyword)

I usually revert my changes this way.

Typical error when trying a checkout in the midst of a merge: $ git co path/to/file =result=> error: path 'path/to/file' is unmerged => so, first run: $ git reset path/to/file, and then the git checkout path/to/file should work.

Not specifying HEAD will make git checkout check out from the index, which is a weaker operation (the content source is the index rather than HEAD). Furthermore I don’t think that makes a difference in this case at all - with the specific problem the question stated. Did you try that?

takeshin

I find git stash very useful for temporal handling of all 'dirty' states.

If you find it useful, please give an explanation on how it would help in this concrete case. How would you use it here?

Git: can't undo local changes (error: path ... is unmerged)

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US