Summary
A developer created a stash (a8f1171) after commit 5014fdd, then made temporary changes in the working tree. They now want to merge the stashed changes with the current working‑tree modifications instead of simply applying or dropping the stash.
Root Cause
- Stash was created on top of a commit that is not the current HEAD.
- The developer edited the same file after the stash, producing a second, unrelated set of changes.
- Git’s default
git stash apply/poptries to apply the entire stash on top of the current index, leading to conflicts or overwriting the temporary edits.
Why This Happens in Real Systems
- Teams often switch branches, stash, experiment, and then need to combine work without losing either set of modifications.
- Stash entries store both the index and the working‑tree state, so re‑applying them assumes the work‑tree is clean.
- When the work‑tree already contains changes, Git cannot automatically decide which version should win.
Real-World Impact
- Lost work: temporary changes may be overwritten by the stash.
- Merge conflicts: developers spend time resolving conflicts that could have been avoided.
- Deployment delays: blocked pipelines while the repository is in an inconsistent state.
- Reduced confidence: frequent stash misuse leads to hesitation in using Git’s powerful features.
Example or Code (if necessary and relevant)
# Save current temporary changes as a new stash (optional)
git stash push -m "temp changes"
# Apply the original stash onto the current work tree, keeping both sets of changes
git stash apply a8f1171 --index
How Senior Engineers Fix It
- Create a temporary branch from the stash point to isolate its changes.
- Cherry‑pick or
git mergethe stash branch into the current branch, allowing normal conflict resolution. - Use
git stash show -p <stash>to inspect the diff before applying. - If the temporary edits are needed, stash them first, then apply the original stash, and finally re‑apply the temporary stash.
- Prefer
git stash branch <new‑branch> <stash>which automatically checks out a new branch with the stash applied, making merges explicit.
Why Juniors Miss It
- They assume
git stash applywill automatically merge changes, not realizing it overwrites the working tree. - Lack of habit to inspect stash contents before applying.
- Unfamiliarity with branch‑based stash workflows (
git stash branch). - Tendency to treat stash as a simple “undo” rather than a full snapshot that may conflict with existing edits.