Accidentally ran git stash drop and thought everything was gone?
Let’s go beyond commands and understand what actually happens internally
Theoretical Understanding (How Git Stores Stash)
-
- A stash is not just a temporary stack entry
- Git stores stash as a commit object (often a merge commit)
- It contains:
- Base commit (HEAD)
- Index state
- Working directory changes
When you run:
| git stash drop |
-
- Git removes the reference (pointer)
- But the actual commit object still exists in .git/objects
Step 1: Check Reflog (First Layer Recovery)
| git reflog |
Output:
| 9554928 (HEAD -> master) HEAD@{0}: reset: moving to HEAD 9554928 (HEAD -> master) HEAD@{1}: commit (initial): initial commit |
Theory Behind This
-
- reflog tracks reference movements (HEAD, branches)
- Stash lives under refs/stash, not always in HEAD history
- In fresh repos, stash may not appear in reflog
That’s why reflog sometimes fails here
Step 2: Deep Scan Using Git FSCK
| git fsck –lost-found |
Output:
| dangling commit d0dd9cf978b19669b2c32f357dbeb4eb7a95f421 dangling commit 611442d8c3f3c7e8c0d3c7c2a5d123456789abcd dangling blob 3f5e8a7b9c1d2e3f4a5b6c7d8e9f0123456789ab |
Theory Behind This
-
- fsck scans all Git objects, not just references
- dangling commit = commit without any pointer
- Dropped stash becomes a dangling commit
- Git keeps it until garbage collection (git gc)
This is why recovery is still possible
Step 3: Identify the Correct Commit
| git show d0dd9cf978b19669b2c32f357dbeb4eb7a95f421 |
Output:
| commit d0dd9cf978b19669b2c32f357dbeb4eb7a95f421 Merge: 9554928 611442d Message: WIP on master: initial commit + Test |
Step 4: Recover the Data
| git checkout –b new-copy d0dd9cf978b19669b2c32f357dbeb4eb7a95f421 |
What Happens Internally
You create a new branch named “new-copy” pointing to that commit. Git restores a full snapshot (files + changes). So this is the only way you can recover your stashed data.