455

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?

Vertexwahn
  • 7,709
  • 6
  • 64
  • 90
mklhmnn
  • 4,770
  • 2
  • 16
  • 8
  • 10
    I wish someone could explain how do we get into this situation, *why* it happens, and why the solution works. – Marcos Dione Aug 05 '17 at 17:09
  • 5
    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. – Arindam Roychowdhury Dec 20 '19 at 09:48
  • I got into this situation after switch to main branch, git pull and do a git stash pop. – Zhou Haibo Sep 14 '22 at 05:40

8 Answers8

735

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
mistiru
  • 2,996
  • 3
  • 11
  • 27
Igor Zevaka
  • 74,528
  • 26
  • 112
  • 128
  • 1
    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. – Patrick Jan 07 '11 at 03:41
  • 21
    For me it required a:
    $ git reset -- foo/bar.txt
    $ git checkout -- foo/bar.txt
    (Notice the extra "--" in between)     – Jan Aug 09 '11 at 17:37
  • For me, git reset resets *all* files, not just the listed one.. Did I do something wrong? – Zds Mar 06 '12 at 13:28
  • 4
    The good syntax is "git reset HEAD file1 file2 ..." then "git checkout -- file1 file2..." – Thomas Decaux Jul 18 '12 at 13:26
  • 3
    It's always amusing when the highest voted answer basically just says "you're doing it wrong" :) – nathanchere Dec 16 '12 at 23:39
  • 6
    An explanation (on what things do) would have been great … – Kissaki Nov 23 '13 at 19:21
  • modern way using `git restore` https://stackoverflow.com/questions/3021161/git-cant-undo-local-changes-error-path-is-unmerged/73707347#73707347 – wisbucky Sep 13 '22 at 17:53
81

This worked perfectly for me:

$ git reset -- foo/bar.txt
$ git checkout foo/bar.txt
fedorqui
  • 275,237
  • 103
  • 548
  • 598
Steffi
  • 841
  • 6
  • 7
17
git checkout origin/[branch] .
git status

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

Joe Hyde
  • 999
  • 7
  • 17
8

If the above answers didn't work try:

git reset --merge
Mateen Ulhaq
  • 24,552
  • 19
  • 101
  • 135
Bruno Cunha
  • 1,680
  • 1
  • 17
  • 15
7

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?

Juan
  • 1,204
  • 1
  • 11
  • 25
  • Here's the way to fix it with `git restore` (although I agree with you it's not intuitive): https://stackoverflow.com/questions/3021161/git-cant-undo-local-changes-error-path-is-unmerged/73707347#73707347 – wisbucky Sep 13 '22 at 17:55
  • @wisbucky... Thanks. If I ever run into that problem again, I'll try that. My fix was to convert the repo to mercurial and use that instead. The friction is far less. – Juan Sep 16 '22 at 20:01
  • 1
    I was hitting this issue on a cherry-pick, and @wisbucky's solution didn't cut it. Using `--ours` did what I was after, just discarding the incoming cherry picked file. @Juan you're totally right about those warning messages needing to say what they did't do, not just why they didn't do it. And a bit more explanation that the ambiguity from the conflict needs to be resolved (by using `--ours`, etc) would be super helpful to this error message. – Ryan Hiebert Nov 25 '22 at 15:21
1

The "modern" way to fix the unmerged path error, which can happen when you pop your stash, using the restore command (since git v2.23, Aug 2019):

# unstage the file
git restore --staged myfile

# restore the file (lose your working dir changes)
git restore myfile
wisbucky
  • 33,218
  • 10
  • 150
  • 101
-3
git checkout foo/bar.txt

did you tried that? (without a HEAD keyword)

I usually revert my changes this way.

zed_0xff
  • 32,417
  • 7
  • 53
  • 72
  • 1
    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. – michael Feb 12 '13 at 05:37
  • 2
    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? – Kissaki Nov 23 '13 at 19:19
-4

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

takeshin
  • 49,108
  • 32
  • 120
  • 164
  • 4
    If you find it useful, please give an explanation on how it would help in this concrete case. How would you use it here? – Kissaki Nov 23 '13 at 19:21