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

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?

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

This worked perfectly for me:

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

git checkout origin/[branch] .
git status

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

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?

If the above answers didn't work try:

git reset -–merge

git checkout foo/bar.txt

did you tried that? (without a HEAD keyword)

I usually revert my changes this way.

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