Your git stash pop conflicts — what state is the repository in and how do you finish safely?

## Why a stash restore can conflict at all A stash is not a file copy. Git merges the stash's recorded working-tree state into your current `HEAD`, using the commit you were sitting on when you stashed as the merge base. If that branch has since moved — someone else's commits pulled in, a rebase, a switch to a different branch entirely — the same lines may have changed on both sides, and Git cannot decide for you. The fact that stashes are branch-agnostic makes this common: `refs/stash` is one repository-wide list, so it is entirely normal to pop onto a branch that is nowhere near where the work was created. ## The exact state after a conflicting pop ``` $ git stash pop Auto-merging src/parser.py CONFLICT (content): Merge conflict in src/parser.py The stash entry is kept in case you need it again. ``` Concretely: - **Conflicting files** contain conflict markers delimiting your branch's version and the stash's version. - **Those paths are unmerged in the index** — `git status` lists them under "Unmerged paths", and `git ls-files -u` shows the multiple stages. - **Files that applied cleanly are staged.** This surprises people: a conflicted stash application leaves the non-conflicting part staged rather than as plain working-tree changes. - **The stash entry survives.** `pop` is `apply` then `drop`, and the drop only happens on a clean apply. `git stash list` still shows it. That last point is the reassurance the question is really testing: a conflicted pop cannot lose your stash. ## Finishing it 1. `git status` — see which paths are unmerged. 2. Resolve each conflicted file: edit out the markers and keep the intended content, or use `git checkout --ours` / `--theirs` on a path when one side wins wholesale (during a stash application, *ours* is your current branch's content and *theirs* is the stash's). 3. `git add <file>` for each resolved path to mark it resolved. 4. `git stash drop` to remove the entry now that you have the content — otherwise it lingers and gets applied twice later. 5. Commit when you are ready. Note that the resolved result is staged, so review with `git diff --cached` before committing rather than assuming the split matches what you had. ## Backing out instead If the restore was a mistake — wrong branch, wrong entry — you do not have to resolve anything. `git reset --hard` puts the working tree and index back to `HEAD`, discarding the half-applied merge. The stash entry is still in the list, so retry wherever it belongs. The only thing you lose is any *other* uncommitted work you had at the time, which is the reason to prefer popping into a clean tree. ## The better tool when the base moved: `git stash branch` When the conflict comes from the branch having moved a long way since you stashed, the cleanest fix is not to fight the merge: ``` git stash branch wip/parser stash@{0} ``` This creates a new branch **at the commit the stash was made on**, checks it out, applies the stash there — where the merge base is exact, so it applies cleanly — and drops the entry if the application succeeded. You then have your work as ordinary changes on a branch and can integrate it with a normal merge or rebase, which is a much better place to resolve the conflict. ## Why forgetting the drop matters Since the entry is kept, a resolved-but-not-dropped stash stays at `stash@{0}`. A week later, another `pop` reapplies changes that are already committed, producing a confusing conflict against your own work. Make `git stash drop` part of the muscle memory, and `git stash list` a habit after finishing a restore. ## Prevention - Pop into a **clean** working tree so a `reset --hard` escape hatch is free. - Pop promptly — stashes rot as the branch moves. - Message your stashes with `-m` so you can identify entries after a few days. - For work that must survive more than an afternoon, use a branch or a worktree instead of a stash. ## What interviewers listen for The key facts: it is a merge; the entry is kept on conflict; cleanly-applied content ends up staged; you must drop the entry yourself; `reset --hard` is a safe abort because the entry survives; and `git stash branch` is the right escape when the base has moved.