git fsck

Finding Dangling Objects with fsck

Some objects are referenced by no ref and no reflog entry at all: a dropped stash, a replaced tag, a commit made on a detached HEAD long ago. git fsck checks the object database and lists these dangling objects, the tips of whatever is unreachable:

Finding the dropped stash of Section 2.8.3 and putting it backShell
git fsck --no-progress
git stash show 1c6cfe0
git stash store -m "README wording" 1c6cfe0
git stash list
Output
dangling commit 1c6cfe0012a4413f1f8ff8c82656742f7dbcc92c
dangling tree 5aba6d9730506fdfe1a120c436d1394d48a15909
dangling tag 5eee635e5488b78054656fed0ffe68ca99a9dc8b
dangling tree 81eab11383dd4694fff4c4a06a1c275c6986087e
dangling commit f43823a00fcc6347e4a426b0b458dc07e8a96c58
dangling tag c4f127803a6b30154e212caf77111fea0c20e01c
dangling tree cb9f53d49683f32621254207bb7bbe6ca5b4379c
 README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
stash@{0}: README wording

Every entry has a story from this chapter. 1c6cfe0 is the README stash that git stash drop removed, and f43823a the migration-runner stash that pop removed after applying it; c4f1278 is the try-annotated tag object of Tag Types, and 5eee635 the unsigned v1.1.0 that the signed tag replaced. Among many, look for stashes by their "On main:" subject (git log --no-walk <hashes>). git stash store put the stash back on the list; git branch rescued <hash> does the same for any commit. Files that were staged but never committed survive as dangling blobs: git fsck --lost-found copies them into .git/lost-found/other/, the last hope after a git reset --hard wiped out added changes.