Fix: git stash pop – CONFLICT, local changes would be overwritten, no stash entries found

The Error

You run git stash pop and hit one of these errors:

Conflict after popping:

Auto-merging src/app.js
CONFLICT (content): Merge conflict in src/app.js
The stash entry is kept in case you need it again.

Local changes would be overwritten:

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

No stash entries found:

No stash entries found.

Could not restore untracked files:

error: Could not restore untracked files from stash entry

Each of these has a different cause and a different fix. This article covers all of them.

Why This Happens

Conflicts after git stash pop

git stash pop replays your stashed changes on top of the current working tree. If the branch has changed since you stashed — different lines in the same file, or structural changes that overlap with your stash — Git cannot cleanly apply the diff. It inserts conflict markers just like a merge conflict.

Important: When a conflict occurs, Git does not drop the stash. The stash entry remains in git stash list so you can retry or recover.

”Local changes would be overwritten”

This means you have uncommitted modifications in files that the stash also modifies. Git refuses to apply the stash because it would overwrite your current changes. Git will not silently destroy your work.

”No stash entries found”

Your stash stack is empty. Either you already popped or dropped all stash entries, you are in a different repository than you think, or the stash was never created in the first place.

”Could not restore untracked files”

Your stash contains untracked files (created with git stash -u or git stash --include-untracked), but files with the same names already exist in your working directory. Git will not overwrite existing files.

Fix 1: Resolve Conflicts After git stash pop

When git stash pop produces conflicts, treat it like a merge conflict. The stash is preserved — it is not dropped on conflict.

Step 1: Check which files have conflicts:

git status

Look for files listed as both modified under “Unmerged paths.”

Step 2: Open each conflicting file and resolve the conflict markers:

<<<<<<< Updated upstream
const API_URL = "https://api.example.com/v2";
=======
const API_URL = "https://staging.example.com/v1";
>>>>>>> Stashed changes

Choose the version you want, or combine them. Remove all marker lines (<<<<<<<, =======, >>>>>>>).

Step 3: Stage the resolved files:

git add src/app.js

Step 4: The stash entry was not dropped (Git keeps it on conflict). Once you are satisfied with the resolution, drop it manually:

git stash drop

If you want to start over, reset the conflicted files and try again:

git checkout -- src/app.js
git stash pop

Fix 2: Handle “Local Changes Would Be Overwritten”

You have uncommitted changes in files that overlap with the stash. You need to move your current changes out of the way first.

Option A: Commit your current changes first.

git add .
git commit -m "WIP: save current work"
git stash pop

You can amend or squash the WIP commit later.

Option B: Stash your current changes too.

git stash          # stash current changes (goes to stash@{0})
git stash pop stash@{1}  # pop the original stash (now at index 1)

After popping the original stash, apply your new stash:

git stash pop      # pops stash@{0}, which is your current changes

Option C: Use git checkout -- to discard current changes.

Only do this if you do not care about your current uncommitted work:

git checkout -- src/app.js
git stash pop

Warning: This permanently discards your uncommitted changes to that file.

Fix 3: Handle “No Stash Entries Found”

First, confirm the stash is truly empty:

git stash list

If this returns nothing, the stash stack is empty.

Check you are in the right repo. Stashes are local to each repository. If you have multiple clones or worktrees, you may have stashed in a different one:

git rev-parse --show-toplevel

This shows the root of the current repository. Make sure it is the one you expect.

Check if you are in a different worktree. If you use git worktree, each worktree shares the same stash list. But if you opened a completely separate clone, it has its own stash.

Recover a dropped stash. If you accidentally dropped or popped a stash and need it back, see the “Recovering a Dropped Stash” section below.

Fix 4: Handle “Could Not Restore Untracked Files”

This error occurs when you stashed with --include-untracked (or -u), and files with the same names now exist in your working directory.

Option A: Move or delete the conflicting files first.

Check which untracked files the stash contains:

git stash show --include-untracked stash@{0}
git stash show stash@{0} -u

Then move or remove the existing files:

mv src/newfile.js src/newfile.js.bak
git stash pop

Option B: Use git stash branch to apply cleanly.

This creates a new branch from the commit where the stash was originally created and applies the stash there. Since the branch matches the original state, conflicts are impossible:

git stash branch recover-stash stash@{0}

This checks out a new branch at the original stash point, applies the stash (including untracked files), and drops it. You can then merge or cherry-pick from that branch.

git stash pop vs git stash apply

Both commands replay stashed changes onto your working tree. The difference:

git stash apply is safer because the stash entry is always preserved. If something goes wrong, you still have it. Use git stash drop to remove it later when you are confident.

# Safer workflow
git stash apply
# verify everything looks good
git stash drop

Stashing Untracked and Ignored Files

By default, git stash only stashes tracked files that have modifications. Untracked and ignored files are left behind.

To include untracked files (new files not yet added to Git):

git stash --include-untracked
# or the shorthand
git stash -u

To include everything, including files matched by .gitignore (build artifacts, node_modules, etc.):

git stash --all
# or
git stash -a

Warning: --all can stash a large amount of data if you have big ignored directories. Use it deliberately.

Stashing Specific Files

You do not always want to stash everything. Git offers several ways to stash selectively.

Stash specific files only:

git stash push src/app.js src/config.js

Stash with a descriptive message:

git stash push -m "WIP: refactor auth module"

This makes git stash list output much more useful:

stash@{0}: On main: WIP: refactor auth module
stash@{1}: WIP on main: abc1234 Previous commit message

Stash interactively (choose hunks):

git stash push --patch

Git walks through each change hunk and asks whether to stash it. This is useful when you have unrelated changes in the same file and want to stash only some of them.

Managing Multiple Stashes

The stash is a stack. The most recent stash is stash@{0}, the one before it is stash@{1}, and so on.

List all stashes:

git stash list

Show what a specific stash contains:

git stash show stash@{2}         # summary (files changed)
git stash show -p stash@{2}      # full diff

Pop or apply a specific stash (not just the latest one):

git stash pop stash@{2}
git stash apply stash@{1}

Drop a specific stash without applying it:

git stash drop stash@{2}

Clear all stashes:

git stash clear

Warning: git stash clear is irreversible. All stash entries are permanently deleted.

Using git stash branch

If your stash conflicts badly with the current branch state, create a new branch from the point where you originally stashed:

git stash branch my-recovered-work stash@{0}

This command:

1. Creates and checks out a new branch (my-recovered-work) at the commit where the stash was created.
2. Applies the stash.
3. Drops the stash if the apply was successful.

Since the branch starts from the exact commit where you stashed, the apply is guaranteed to be clean. No conflicts. You can then merge this branch into your target branch using the normal merge workflow.

Recovering a Dropped Stash

If you accidentally dropped or cleared a stash, the data is not immediately gone. Git keeps dangling commits for a while (until garbage collection runs, typically 30 days).

Step 1: Find the dangling stash commit:

git fsck --no-reflog | grep commit

This lists unreachable commits. Stash entries appear here.

Step 2: If the list is long, look for stash-like commits:

git fsck --no-reflog | grep commit | while read type hash; do
  git log --oneline -1 "$hash"
done

Look for entries with messages like WIP on main: or your custom stash message.

Step 3: Once you find the right commit hash, recover it:

git stash apply <commit-hash>

Or create a branch from it:

git branch recovered-stash <commit-hash>

Note: This only works if Git has not run garbage collection yet. The default retention is 30 days for unreachable objects. Do not run git gc before recovering.

Still Not Working?

Stash pop does nothing (no error, no changes)

If git stash pop completes silently but your files do not change, the stash may have been created from the exact same state. Check what the stash contains:

git stash show -p stash@{0}

If the diff is empty, the stash captured no meaningful changes. Drop it and move on:

git stash drop

Stash created on a different branch

Stashes are not branch-specific. You can create a stash on feature-A and apply it on main. However, if the branches have diverged significantly, you may get conflicts. Use git stash branch to apply the stash at its original commit point, then merge from there.

Permission errors or locked index

If you see fatal: Unable to create '.git/index.lock': File exists, another Git process is running or crashed:

rm .git/index.lock

Then retry your stash operation. See Fix: fatal: not a git repository for more on .git directory issues.

Stash contains staged and unstaged changes mixed up

By default, git stash collapses staged and unstaged changes together. When you pop, everything comes back as unstaged. To preserve the staging state:

git stash push --keep-index    # stash only unstaged changes, keep staged
git stash pop --index          # restore and preserve the original staged/unstaged split

If you stashed without --keep-index and need the staged state back, git stash pop --index attempts to recreate it. If that fails (due to conflicts with the index), try without --index and manually re-stage what you need.

Partial stash left working directory in a broken state

If you used git stash push --patch and the remaining code does not compile or work, you can abort and get everything back:

git stash pop

This restores the stashed hunks. If there are conflicts, resolve them as described in Fix 1.

Related: Fix: CONFLICT – Merge conflict | Fix: git push rejected – non-fast-forward | Fix: detached HEAD state | Fix: fatal: not a git repository