Fix 'error: stash apply conflicts' and failed stash pop

Overview
Quickstart
Minimal working example
Step-by-step resolution
Common errors and quick fixes
Pitfalls to avoid
Performance notes
FAQ

Overview

When git stash apply or git stash pop reports conflicts, Git tried to merge stashed changes into your working tree and found overlaps. The stash is safe: pop drops the stash only if the apply succeeds cleanly. You can recover, resolve, or retry safely.

This guide shows quick fixes, a reproducible example, safe recovery patterns (git stash branch), and prevention tips.

Quickstart

Ensure a clean working tree before applying stashes: git status should be clean.
Prefer resolving on a temporary branch: git stash branch fix-stash stash@{0}.
Resolve conflicts, git add resolved files, and commit.
If you accidentally applied to the wrong branch, abort with git reset --hard (stash remains) and try again on the correct branch.
After success, drop the stash: git stash drop stash@{0} or let pop do it for you.

Minimal working example

The following reproduces a stash conflict and shows two safe resolutions.

# 1) Setup
mkdir demo && cd demo
git init -q
printf "line1\nline2\n" > app.txt
git add app.txt && git commit -qm "base"

# 2) Create a stash on main
sed -i.bak 's/line2/line2-from-stash/' app.txt && rm -f app.txt.bak
git stash push -m "tweak line2" -q -- app.txt

# 3) Make a conflicting change on main
sed -i.bak 's/line2/line2-on-main/' app.txt && rm -f app.txt.bak
git commit -am "conflicting main change" -q

# 4) Applying the stash will conflict
set +e
git stash apply  # or: git stash pop
set -e
# You will see: "error: could not apply ..." and conflict markers in app.txt

# Resolution path A: do it safely on a branch
# (If you already applied and conflicted, you can abort and retry.)
# Abort the partial apply on main safely:
git reset --hard  # discards partial merge; stash is still present
# Create a branch from current HEAD and apply the stash there
git stash branch fix-stash stash@{0}
# Resolve conflicts in app.txt, then:
# choose either ours/theirs quick resolution, or edit manually
# e.g., accept stashed version for the file:
#   git checkout --theirs -- app.txt    # "theirs" is the stash during stash branch
# or accept current branch version:
#   git checkout --ours -- app.txt
# After resolving:
git add app.txt
git commit -m "Apply stash with resolution" -q
# Optionally drop the stash if not auto-dropped
git stash drop stash@{0} 2>/dev/null || true

# Resolution path B: finish where you are
# If you kept the conflict on main (didn't reset), resolve markers, then:
#   git add app.txt
#   git commit -m "resolve stash apply"
# The stash is kept because apply conflicted; drop it manually if done:
#   git stash drop stash@{0}

Step-by-step resolution

Verify state

Run git status. If you have unrelated changes, commit or stash them before proceeding.
List stashes: git stash list. Identify the one you need, e.g., stash@{0}.

Inspect the stash

Show a summary: git stash show stash@{0}.
See the full patch: git stash show -p stash@{0} or git show stash@{0}.

Use a safe workspace

Best practice: git stash branch <branch-name> <stash-ref>.
This creates a new branch at the commit where you run it, applies the stash there, and is conflict-friendly.

Apply with index (optional)

If you originally stashed with staged changes, preserve index state: git stash apply --index stash@{0}.
If this conflicts, resolve as below.

Resolve conflicts

Open each conflicted file, search for <<<<<<<, =======, >>>>>>>.
Choose changes manually or use helpers:
- Keep current branch version: git checkout --ours -- <file> or git restore --source=HEAD -- <file>.
- Keep stashed version: in stash branch context, --theirs corresponds to the stash: git checkout --theirs -- <file>.
Stage resolved files: git add <file>....
Verify with git status and git diff --staged.
Commit: git commit -m "Apply stash with conflict resolution".

Clean up

If you used git stash pop and it conflicted, the stash is retained. Drop it when satisfied: git stash drop stash@{0}.
If you used git stash apply, the stash remains by design; drop it after successful commit.

Abort a bad attempt

To discard a partially applied stash and revert the working tree/index to HEAD: git reset --hard.
Your stash is still available. Re-apply on the correct branch or with a different strategy.

Common errors and quick fixes

Error/message snippet	What it means	Quick fix
error: could not apply <hash>	Merge conflict applying stash	Resolve conflicts, `git add`, `git commit`, then drop stash if desired
`fatal: Working tree is dirty` (when stashing again)	You have unresolved merges/changes	Commit, re-stash, or `git reset --hard` to abort partial apply
untracked files would be overwritten	Untracked files collide with stashed tracked files	Move/commit/untrack files, or include them in stash via `git stash push -u`
pathspec did not match any files	File set changed since stash	Inspect with `git stash show`, apply manually or cherry-pick parts with `git checkout <stash> -- <path>`

Pitfalls to avoid

Using git stash pop on a non-clean tree: increases conflict risk and makes recovery harder. Prefer a clean tree or use git stash branch.
Forgetting the index: if you stashed with staged changes, use --index when applying to preserve intent.
Large stashes with mixed unrelated changes: harder merges. Create smaller, topic-specific stashes instead (pathspecs or separate stashes).
Assuming pop always drops the stash: it drops only on a clean apply. After conflicts, the stash is kept; remember to drop it once you are done.

Performance notes

Big binary files or many renames in a stash slow down apply/merge. Prefer committing binaries or excluding them from stashes.
If viewing large stash diffs is slow, avoid rename detection during inspection: git -c diff.renames=false stash show -p stash@{0}.
Applying on a branch close to where the stash was created (minimal divergence) reduces conflicts and speeds up the merge.
Keep stashes short-lived; the farther HEAD moves, the more expensive and conflict-prone the apply.