Resolve a git stash pop conflict (and undo one)

Does this match your situation?

• 'CONFLICT (content): Merge conflict in <file>' immediately after git stash pop.
• git stash list still shows the entry you thought you popped.
• You want the working tree back the way it was before you popped.
• 'error: could not restore untracked files from stash'

Step-by-step fix

1. Check the stash is still there — it is

   pop is apply followed by drop, and the drop only runs on a clean apply. A conflict stops it, so the entry survives. This single fact is what makes everything below safe to try.

   step 1Copy

   git stash list
   git stash show -p stash@{0} | head -40
   

2. Path A: resolve the conflict and keep going

   Mechanically this is an ordinary merge conflict — the markers mean what they always mean. Your side is what is currently in the working tree; theirs is what was stashed.

   step 2Copy

   git status
   # edit each conflicted file, delete <<<<<<< ======= >>>>>>>
   git add .
   git stash drop        # you must do this yourself after a conflict
   

   💡Forgetting the drop is how duplicate stash entries pile up. Nothing else removes it.

3. Path B: undo the pop entirely

   git checkout . discards the half-merged mess and returns to the tree as it was before the pop, with the stash untouched. This is the right choice when you popped onto the wrong branch or the wrong commit.

   step 3Copy

   git checkout .
   # or, to clear the conflicted merge state as well:
   git reset --merge
   
   git stash list        # your entry is still there
   

   🚨This discards uncommitted changes that were in the tree before the pop as well. Check git stash list first if you are unsure.

4. Retry cleanly with apply instead of pop

   apply never removes the stash, so a second conflict costs you nothing. Use it whenever a pop is likely to be awkward, and drop the entry by hand once you are satisfied.

   step 4Copy

   git switch correct-branch
   git stash apply stash@{0}
   # happy with the result?
   git stash drop stash@{0}
   

5. Or land the stash on its own branch

   stash branch creates a branch from the commit the stash was made on and applies it there, which means the conflict usually disappears entirely — the tree matches what the stash expected.

   step 5Copy

   git stash branch recovered-work stash@{0}
   

   ✅On success this drops the stash automatically, because it applied cleanly.

6. Untracked files that would not restore

   Files stashed with -u are not restored if a file of the same name already exists. Move the collision aside and apply again.

   step 6Copy

   git stash show --include-untracked stash@{0}
   mv newfile.txt newfile.txt.bak
   git stash apply stash@{0}
   

Why this works

A stash is not a patch file — it is a real commit (two or three, in fact: one for the index, one for the working tree, and one more for untracked files) parked on a ref no branch points at. Applying it is therefore a genuine three-way merge between what you stashed and where you are now, which is exactly why it can conflict. It also explains the safety property people rely on without knowing why: pop is defined as apply-then-drop, and Git will not run the drop unless the apply succeeded cleanly. The commits are still in the object database, still referenced by refs/stash, and still recoverable — even if you later drop the entry, since git fsck can find those commits until garbage collection runs.

If that didn’t work

• git stash show -p stash@{0} > /tmp/stash.patch gives you the changes as a file to apply by hand.
• git checkout --theirs <file> during the conflict takes the stashed version of that file wholesale.
• If you already dropped the stash, git fsck --unreachable finds the commit and git stash apply <hash> restores it.
• Enable rerere so a stash you keep re-applying resolves itself the same way every time.

How to stop it happening again

• Prefer apply over pop when you are unsure — dropping later is one command.
• Stash with a message: git stash push -m "wip: login form" makes the list readable.
• Pop onto the branch you stashed from; most conflicts come from popping somewhere else.
• For anything longer than a coffee break, commit on a scratch branch rather than stashing.

Commands used in this guide

Frequently asked questions