Fix 'git stash pop' Failing with 'Your local changes would be overwritten by merge'

What Happened

You stashed your work, did something else, then ran git stash pop — and got slapped with this:

error: Your local changes to the following files would be overwritten by merge:
        src/main.py
Please commit your changes or stash them before you merge.
Aborting

The stash didn't apply. But nothing was lost — your stash is still sitting in the stack. Git refused to continue because you already have uncommitted changes to src/main.py, and applying the stash would clobber them.

Why Git Aborts

Running git stash pop triggers a merge of the stashed diff back into your working tree. If a file already has uncommitted edits, Git has no safe way to apply the stash on top — it would silently wipe out whatever you'd been working on. So it bails early.

The most common scenario that leads here:

• You stash changes to src/main.py.
• You switch to another branch, make a quick fix, switch back.
• Or — and this happens constantly — you forget the stash exists and start editing src/main.py again.
• You run git stash pop. It explodes.

Start by figuring out exactly what you're dealing with:

# See which files the stash touches
git stash show

# See what's currently uncommitted
git status
git diff src/main.py

Fix 1 — Commit or Stash Your Current Changes First (Recommended)

Clear your working tree before the pop. Two ways to do it:

# Option A: commit what you have now
git add src/main.py
git commit -m "WIP: current changes before stash pop"
git stash pop

# Option B: stash your current changes on top
git stash          # saves current changes as stash@{0}
git stash pop stash@{1}  # pops the original stash (now shifted to index 1)
# Resolve any conflicts, then:
git stash pop      # pops the WIP stash you just created

Option B keeps everything in the stash stack. After the first pop, you may still hit a merge conflict — that's normal. Git marks the conflict regions with <<<<<<< markers so you can resolve them manually.

Fix 2 — Discard Your Current Working Tree Changes

Sometimes the changes blocking you aren't worth keeping — a half-finished experiment, some debug prints, whatever. Just throw them out:

# Discard changes to the specific file
git checkout -- src/main.py

# Then retry
git stash pop

Need to nuke everything uncommitted?

git restore .   # Git 2.23+
# or
git checkout -- .

Warning: This is permanent. Discarded working tree changes are gone — Git has no recycle bin for them. Double-check git diff before running either command.

Fix 3 — Force a 3-Way Merge with git apply

Both sets of changes matter, but git stash pop keeps aborting? Export the stash as a patch and let Git attempt the merge itself:

git stash show -p | git apply --3way

Instead of aborting on conflict, --3way makes Git do its best and leaves conflict markers (<<<<<<< / >>>>>>>) in any file it couldn't auto-resolve. You fix those manually.

# Check which files need attention
git status

# Edit src/main.py to resolve conflict markers, then:
git add src/main.py

# Drop the stash entry — it was applied manually
git stash drop

Fix 4 — Apply the Stash Without Removing It

Not sure the apply will go smoothly? Use git stash apply instead of pop:

# Apply without dropping (stash stays in the stack)
git stash apply

# Resolve conflicts, then drop the stash manually
git stash drop

The only difference from pop: the stash entry survives until you explicitly drop it. If something goes sideways, the stash is still there as a safety net. Good default when you're not fully confident about the outcome.

Verification

Quick sanity check before moving on:

# Stash stack should be empty (or one entry shorter)
git stash list

# Working tree should show only your expected changes
git diff HEAD

# No leftover conflict markers
grep -r '<<<<<<<' src/

Empty git stash list plus a clean git status? You're done.

Preventing This Next Time

A few habits that eliminate this entirely:

• Run git status before git stash pop. Thirty seconds of checking beats ten minutes of untangling conflicts.
• Be explicit about which stash you're popping. With multiple entries in the stack, git stash pop stash@{1} is much safer than letting Git guess.
• Don't rely on stashes for anything longer than a few minutes. For context switches that last an hour or a day, a WIP commit on a temporary branch is far more reliable.
• Name your stashes. git stash push -m "refactor: before adding auth layer" takes five extra seconds and makes git stash list actually readable.