Chapter 2.8 — Dropped Stash Recovery☕ 12 min read

Dropped Stash Recovery

Drop sirf reference hataata hai, commit nahi. Dangling commits reflog se mil jaayenge. Yeh secret trick bahut kam log jaante hain.

01Dropped Stashes are Dangling Commits

git stash drop removes a stash entry from the list. git stash clear removes ALL entries at once — no confirmation, no undo button.

But here is the critical insight: stashes are just special commits. They live in .git/refs/stash as commit objects. When you drop a stash, Git deletes the reference, not the commit itself.

The dropped stash becomes a dangling commit — an object that exists in the store but is not reachable from any branch, tag, or reference.

These dangling commits survive until git gc (garbage collection) removes them. The default expiry is 90 days for reflog entries and 30 days for unreachable objects.

If you recently dropped a stash, you can almost always recover it. The key is knowing where to look: reflog, fsck, or the stash log file.

# The accident
git stash list
# stash@{0}: On main: important work
git stash drop stash@{0}
# Dropped stash@{0}

# Panic! But wait...
git stash list  # empty

# The stash commit still exists in the object store
# We just need to find its hash.

Dropping a stash only removes the pointer, not the data. Think of it like deleting a shortcut from your desktop — the actual file is still on disk. Git does not immediately destroy the commit object. It becomes "dangling" — unreachable but intact. This is your window for recovery.

02Method 1 — Find via Reflog

git reflog records every HEAD movement — commits, checkouts, merges, stash creates, and stash drops. It is your first stop for recovery.

When you create a stash, Git records it in the reflog. When you drop a stash, the creation entry still exists in the reflog with the commit hash.

Look for entries like stash: add important work or WIP on main. The hash next to that entry is your dropped stash.

Once you have the hash:

git stash apply <hash> — apply the stash to your working directory
git checkout <hash> -- <file> — recover specific files only
git branch recovered-stash <hash> — create a permanent branch from it

git reflog show stash specifically shows the stash reflog, but only works if the stash reference still exists.

# Check reflog for stash entries
git reflog --all | grep stash
# abc1234 HEAD@{2}: WIP on main: important work

# Or check the general reflog
git reflog | head -10
# Look for "stash:" entries

# Once you find the hash, apply it
git stash apply abc1234
# Or create a branch from it
git branch recovered-stash abc1234

# If you only need specific files
git checkout abc1234 -- path/to/file.js

💡 Pro Tip: The reflog is local to your machine and is NOT transferred to remote repositories. It is also limited by entry count (default 250 per ref) and time (default 90 days). If your reflog entry has expired, move to Method 2: fsck.

03Method 2 — Find via git fsck

If the stash reflog entry is gone or expired, use git fsck to find dangling commits.

git fsck --no-reflogs --unreachable lists all objects not reachable from any branch or reflog. This is your last resort for finding lost stashes.

Look for "unreachable commit" entries in the output. Each one has a hash you can inspect.

git show <hash> to inspect each dangling commit and find your stash. Stash commits have a special structure with multiple parents — the working directory commit and the index commit.

Once you identify your stash among the dangling commits, recover it with git stash apply, git cherry-pick, or by creating a branch.

# Find all unreachable objects
git fsck --no-reflogs --unreachable 2>/dev/null | grep commit
# unreachable blob abc1111
# unreachable commit def2222
# unreachable commit ghi3333  <-- might be your stash!

# Inspect each dangling commit
git show def2222
# If it shows your stashed changes, that is it!

# Apply it as a stash
git stash apply def2222

# Or cherry-pick specific changes
git cherry-pick def2222

# Or create a branch from it
git branch stash-recovery ghi3333

Stash commits have TWO or THREE parents — one for the working directory state, one for the index state, and optionally one for untracked files. Regular commits have only one parent. This is how you can identify a stash commit among dangling objects: look for commits with merge-like structure that are not on any branch.

04Method 3 — Read the Stash Log File

Stash operations are logged in .git/logs/refs/stash. If the stash ref still has a log, you can read it directly to find dropped stash hashes.

cat .git/logs/refs/stash shows the history of all stash operations — creates, drops, pops, everything.

Each line has the old hash, new hash, author, timestamp, and operation description. This file is human-readable and persists even after dropping individual stashes.

The hashes in this file are the stash commit hashes. Use git show to inspect each one and find the stash you dropped.

This method works even when git reflog has been pruned, because the stash log file is separate from the general reflog.

# Read the stash log directly
cat .git/logs/refs/stash
# abc1111 def2222 Sai Kumar <sai@dev> 1234567890 +0530  stash: add important work
# def2222 ghi3333 Sai Kumar <sai@dev> 1234567891 +0530  stash drop on main

# The hashes in this file are the stash commits
# Use git show to inspect each one
git show def2222

# Recover the stash
git stash apply def2222
# Or: git checkout def2222 -- .

💡 Pro Tip: The stash log file only exists if you have ever used git stash in the repository. If all stashes are cleared and the reflog entry expires, this file may also be cleaned up. But it often survives longer than the general reflog, making it a useful intermediate recovery method.

05Prevention — Avoid Accidental Drops

Prevention is better than recovery. Dropped stash recovery is an emergency technique, not a workflow. Here are practices that make stash disasters far less likely:

Use git stash apply instead of pop — apply keeps the stash in the list until you manually drop it. No accidental loss.
Use descriptive messages: git stash push -m "WIP: feature X with bug Y fixed". Descriptive stashes are harder to accidentally drop.
For important work, commit to a branch instead — branches are permanent, stashes are temporary. git checkout -b backup/login-wip then commit.
Back up critical stashes by creating branches: git stash branch stash-backup stash@{0}. This turns your stash into a permanent branch.
Run git stash list before any destructive stash operations — always verify what you are about to drop.
Never rely on dropped stash recovery — it works, but it is an emergency measure with a time limit.

# Prevention 1: Descriptive stash messages
git stash push -m "WIP: login feature - auth token not working"

# Prevention 2: Apply, do not pop
git stash apply stash@{0}
# Verify, then manually drop
git stash drop stash@{0}

# Prevention 3: Commit instead of stash
git checkout -b backup/login-wip
git add -A && git commit -m "WIP: login feature"
# Much safer than stashing

# Prevention 4: Create a branch from a stash for backup
git stash branch stash-backup stash@{0}
# Now your stash is a permanent branch!

The golden rule of stashing: Stashes are temporary parking spots, not long-term storage. If the work matters, commit it to a branch. A branch costs nothing, survives garbage collection, and can be pushed to remote. A stash is one drop away from becoming a recovery emergency.

Lo kar liya — Key Points:

✅ Dropped stashes are NOT immediately deleted — the commit objects still exist until git gc removes them
✅ Use git reflog | grep stash to find the hash of a recently dropped stash
✅ Use git fsck --no-reflogs --unreachable to find older dangling commits if reflog has expired
✅ Once you find the hash, recover with git stash apply <hash> or git checkout <hash> -- <file>
✅ The stash log at .git/logs/refs/stash keeps a record of all stash operations
✅ Prevent dropped stash panic by using apply instead of pop and committing important work to branches

Previous2.7 — Stash Pop Conflict 📋 All Chapters Next Chapter2.9 — Pushed to Wrong Remote →