Git stash-pop-conflict Reapplying a stash hit conflicts, and the stash entry was deliberately kept.

dev@local: ~/project — git

dev@local~/project$git stash pop

error: stash pop conflict

Diagnostics Translation

Reapplying a stash hit conflicts, and the stash entry was deliberately kept.

waiting for resolution...

MediumVersion Control System

Reviewed for reference consistency: August 11, 2026

Code is Safe

SECURE

Git has paused the operation to protect your code. No data has been lost or corrupted.

What To Know

This state means a stash application collided with later work: the files hold conflict markers, and the stash entry itself remains stored until you drop it deliberately.

Where Did It Fail?

Working Tree

Your local files

add

Staging Index

Prepared changes

commit

Local Repo

Commit history

push/fetch

Remote Server

GitHub/GitLab

Git halted to protect the uncommitted files in your active working directory.

Commands That Trigger This

$git stash pop

Running after pulling or rebasing the branch the stash was based on

Restoring week-old stashed work onto a heavily refactored tree

$git stash apply stash@{2}

colliding with newer edits to the same files

Technical Background

Unlike a plain pop that drops after success, the conflicted apply behaves like a small merge between the stash's parent commit, the current tree, and the stash itself. The conflict markers carry the labels 'Updated upstream' and 'Stashed changes', so the two sides stay identifiable inside the file.

The entry surviving is a documented safety property, not a leftover: applying with conflicts does not remove the stash, and the working copy confirms it with the line 'The stash entry is kept in case you need it again.'

Once the files are settled and staged, the entry must be dropped manually — the cleanup half never runs after a conflict, so a repeated pop would try to apply the same snapshot a second time.

Underlying Causes

The same files were modified after the stash was pushed

The stash was created on a different branch or commit than it is applied to

Upstream changes overlapped the stashed edits line for line

Binary files in the stash changed on both sides and cannot merge

Frequently Asked Questions

Yes. The entry survived the first conflict, so a repeated pop tries to reapply the same snapshot; drop it once the resolution is staged instead.

'Updated upstream' marks the current branch's content and 'Stashed changes' marks the restored snapshot; with the diff3 conflict style a 'Stash base' section shows the common ancestor.

It applies the stash onto the commit where the stash was originally created, which sidesteps conflicts caused by the branch having moved on.

Related Git States

merge-conflictMedium

Git paused the merge because it cannot automatically resolve overlapping changes.

could-not-apply-commitMedium

Git stopped a rebase or cherry-pick because the commit conflicts with your current code.

could-not-restore-untracked-files-from-stashMedium

Stash application failed while copying the stash's untracked files back out.

unmerged-pathsLow

You have unresolved file conflicts preventing Git from completing the current operation.