Recover a dropped Git stash

A dropped stash may still be recoverable while its commit objects remain in the local repository. Dropping or clearing the stash removes references; it does not guarantee immediate object deletion. Conversely, there is no guaranteed grace period for recovery.

Start with any known object ID

The output from git stash drop may include the removed object's ID. If you have it, inspect that object directly. Otherwise search for unreachable commits:

git fsck --unreachable

Look for unreachable commit entries. Avoid hiding every diagnostic: other repository errors should not be mistaken for a simple missing stash. --no-reflogs can broaden the search by excluding reflogs as reachability roots, but may produce many unrelated candidates. --lost-found is another inspection aid, not a promise that the relevant stash survives.

Inspect candidate stashes

git show --no-patch --format='%H %ci %s' CANDIDATE
git show --stat CANDIDATE
git stash show -p --include-untracked CANDIDATE

A normal stash commit has multiple parents and often a subject beginning with WIP on or On, including a supplied message. Those are clues, not proof. Inspect the content and parent structure before applying it. A generic merge-style git show can miss parts of the stored changes; stash-aware inspection can include untracked content explicitly.

For a date-sorted candidate list in a POSIX shell:

git fsck --unreachable |
  awk '$1 == "unreachable" && $2 == "commit" { print $3 }' |
  while read -r object; do
    git show -s --format='%ct %H %s' "$object"
  done | sort -nr | head

The timestamp comes first, so the sort actually orders by commit time. This does not automatically restrict results to the last week.

Protect and apply the confirmed object

git stash store -m "Recovered stash" CANDIDATE
git stash list
git stash apply 'stash@{0}'

Store only a confirmed stash-shaped commit. Alternatively, git stash apply CANDIDATE applies its changes without adding an entry to the stash list. Preserve current work first; application can conflict or fail to restore an untracked path already occupied by a file. --index attempts to restore the original staged state as well.

Know the recovery limits

Do not run pruning or cleanup while investigating. A garbage-collection run does not necessarily delete every unreachable object, so check availability rather than assuming any previous gc makes recovery impossible. Once the objects are actually gone, look for backups or a separate copy that received the stash content. Ordinary clones do not automatically contain another clone's local stashes.

For important ongoing work, git stash branch recovery-name STASH can create a branch and apply the stash there. It does not automatically commit the changes, so review and commit them before treating the branch as durable saved work. A local stash or branch is not an off-machine backup.

See git-stash, git-fsck, and Git object cleanup.