Git Stash Pop Conflict: How to Resolve It (Tested)

git stash pop fails with a conflict when the change you stashed touches the same lines as a commit made since you stashed. git applies what it can, leaves conflict markers in the file, and exits 1. Unlike a normal pop, the stash is not dropped when this happens — git keeps it on purpose so you don't lose the work. Here is exactly what we saw and the two clean ways out.

1. What we did

In a disposable repo: committed a file, stashed a change to it, committed a different change to the same line on top, then ran git stash pop.

$ git stash pop
Auto-merging f.txt
CONFLICT (content): Merge conflict in f.txt
On branch master
Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
	both modified:   f.txt

no changes added to commit (use "git add" and/or "git commit -a")
The stash entry is kept in case you need it again.

Exit code was 1. git status --short showed UU f.txt (unmerged, both sides modified).

2. The conflict markers are not what you expect

A normal merge conflict labels sides by branch/commit (HEAD vs the branch name). A stash-pop conflict labels them differently:

<<<<<<< Updated upstream
line1-modified-main
=======
line1-modified-working
>>>>>>> Stashed changes

Updated upstream is your current committed state; Stashed changes is what was in the stash. If you only remember "HEAD vs branch" markers from merges, these different labels are the tell that you're resolving a stash conflict, not a merge.

3. Your stash is safe — check before panicking

We confirmed git stash list still shows the entry after the failed pop:

$ git stash list
stash@{0}: On master: wip

git deliberately does not drop the stash on a conflicted pop. You will not lose the stashed work by trying and failing.

4. Clean undo: back out entirely

To abandon the pop and get back to exactly where you were before running it, measured and confirmed:

git reset --hard HEAD

This clears the conflict markers from the working tree and leaves the stash untouched in the list, ready to try again later. (There is no git stash pop --abort flag — reset --hard is the real equivalent.)

5. Resolve and finish properly

If you want to keep going: edit the file to remove the markers (or pick a side wholesale with git checkout --ours f.txt or --theirs f.txt, then git add), then commit if needed. We verified the stash is still listed even after staging and committing the resolution — you must drop it yourself:

git add f.txt
git commit -m "resolved"
git stash drop

Forgetting the final git stash drop is the most common mistake here: the conflict looks resolved, but the same stash will resurface if you ever run git stash pop again.

6. Avoiding it next time

• Run git stash show -p first to see what the stash touches before popping.
• git stash apply instead of pop leaves the stash in place even on success, so a conflict doesn't change whether you need to drop it manually — useful if you want one less thing to track mid-resolution.
• Rebase or merge the branch forward before popping an old stash on a file you know has since changed.

Written with AI assistance. Measured on 2026-10-02 with git 2.47.3 on Linux, plain CLI only (no GUI tool), in a disposable test repo. PlainHeaders is our extension; git is free and open source.