99

So I had a load of changes and some untracked files. I needed to tweak something, so I used git stash -u, modified a couple of things, committed those changes, pushed them, and then tried to git stash pop.

Because I'd modified a couple of files that I'd stashed, I got the following message:

error: Your local changes to the following files would be overwritten by merge:
    file_1.py
    file_2.py
Please, commit your changes or stash them before you can merge.
Aborting

This seems odd, I had committed all new changes, my checkout was clean when I ran the command.

It seems the git stash pop operation un-stashed half of my changes and the untracked files, but if I try and git stash pop again I get output like:

some_file.html already exists, no checkout
some_other_file.html already exists, no checkout
yet_another_file.html already exists, no checkout
Could not restore untracked files from stash

git stash show still shows a list of my stashed changes, but I'm at a loss as to what I do now.

How can I get myself unstuck?

fredley
  • 32,953
  • 42
  • 145
  • 236
  • Possible duplicate of [Cannot apply stash to working directory](http://stackoverflow.com/questions/10508903/cannot-apply-stash-to-working-directory) – Wilfred Hughes Sep 13 '16 at 17:33
  • Related when there are local changes: [git stash -> merge stashed change with current changes](https://stackoverflow.com/a/16613814/2533467) – iFreilicht Aug 10 '17 at 11:17

4 Answers4

175

For those who do have un-committed work, and want to pop their stash without losing that work, here is a way (with thanks to @iFreilicht):

  1. Temporarily stage any uncommitted changes:

     git add -u .

  2. Now you can apply your stash without git complaining (hopefully):

     git stash pop

  3. Now unstage everything, but leave the files as they are now:

     git reset

If step 2 couldn't patch cleanly due to conflicting changes, then you will need to resolve the conflicts manually. git diff should help you find them. git mergetool might help by opening your editor with before and current files.

joeytwiddle
  • 29,306
  • 13
  • 121
  • 110
  • 11
    Whenever I do this I feel like I'm not using git properly.. Found no alternative though. – Joost Oct 24 '16 at 12:47
  • 6
    I managed to find a second way: Instead of committing, run `git add ` for all files that would be overwritten. Then you can `pop`, and then just unstage again with `git reset HEAD`. This has to be a bug of some sort. – iFreilicht Oct 27 '17 at 14:00
  • @Joost Why not stash instead of commit, then turn around and drop the top of the stash stack? `git stash save "junk"` `git stash drop` `git stash pop` – LastStar007 Nov 13 '17 at 21:26
  • Very nice @iFreilicht, I have switched to your method instead! – joeytwiddle Nov 16 '17 at 02:26
  • 3
    LastStar007, we want to keep the current "junk", and pop what is in the stash as well. – joeytwiddle Oct 14 '18 at 08:59
  • 1
    This is great, thanks. It happens.. too often.. that I stash changes because I need to do urgent work on another branch. Then I go back to the original branch and keep working without popping my stash... It's a mess. This totally solves that problem. – little_birdie May 12 '20 at 03:50
  • @little_birdie Not sure if this helps, but I use a git-aware-prompt and when I check out a branch it will remind me whether there [was a stash](https://github.com/joeytwiddle/git-aware-prompt/commit/f3e13a4e9dcf491bef77fd52db9cecfa4211b437) made on that branch, nudging me to pop again. – joeytwiddle Apr 29 '21 at 05:13
  • Ran into a merge conflict...now what – information_interchange May 13 '21 at 01:48
60

I got around this, I think it must have been some kind of bug, as my working directory was clean and up to date.

I ran git checkout . and after that git stash apply worked fine, I got everything back no problems at all. I'd be interested to work out what actually caused it to fail though.

fredley
  • 32,953
  • 42
  • 145
  • 236
  • 1
    For the record, doing this still gave the same errors for me even with a clean working directory. – Taylor D. Edmiston Nov 14 '16 at 20:13
  • 7
    This worked for me... emphasis on the `.` Can someone explain why this works? – Jamie M. Nov 28 '16 at 21:54
  • 7
    For the uninformed, the . is an alias for "all non ignored files recursively", not to be confused with *. But it's 5 years ago, so you know this now. @JamieM. –  Mar 19 '20 at 08:14
  • 2
    I had a clean directory too but I was facing the same error, for me this solution didn't worked. I tried a `git stash apply --index` and it worked, can't really explain what this arg do but as per documentation "attempt to recreate the index" – Milvintsiss Oct 10 '21 at 23:31
3

The stash that was made with -u needs to have the untracked files cleaned away before being apply-ed (and pop is just apply+drop).

Out of general paranoia I'd mv the untracked files somewhere safe, then git stash apply, check everything carefully, and git stash drop once I'm sure I have it all correct. :-)

torek
  • 448,244
  • 59
  • 642
  • 775
  • This doesn't seem to work, I'm starting with a clean working directory with no untracked files, there's nothing to `mv` out of the way! – fredley Nov 13 '13 at 11:01
  • Hm. Might be a bug in `git stash` (I've found one before) ... it would be interesting if you can reproduce this, especially with a small example. – torek Nov 13 '13 at 12:12
0

None of these solutions worked for me. I was using git stash index command to restore a specific stash id. So, I ended up doing a commit of my local changes to local repo. Then git stash index worked for me. And finally I rolled back my commit using git reset (with keep changes). Problem solved.

pkso
  • 1