86

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
  • 31,101
  • 42
  • 135
  • 231
  • 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

145

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.

joeytwiddle
  • 26,898
  • 12
  • 113
  • 100
  • 9
    Whenever I do this I feel like I'm not using git properly.. Found no alternative though. – Joost Oct 24 '16 at 12:47
  • 5
    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
  • 2
    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
57

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
  • 31,101
  • 42
  • 135
  • 231
  • 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
  • 6
    This worked for me... emphasis on the `.` Can someone explain why this works? – Jamie M. Nov 28 '16 at 21:54
  • 5
    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
  • 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
  • 389,216
  • 48
  • 524
  • 664
  • 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