A dangling blob message from git fsck indicates file content that was staged but never committed. This is typically harmless and will be automatically cleaned up by Git's garbage collection.
When Git reports a "dangling blob," it has found file content in its object database that isn't referenced by any commit, tree, or tag. In Git's internal structure, a "blob" is how Git stores file contents—each unique file version gets its own blob object identified by a SHA-1 hash. A blob becomes "dangling" when it exists in the database but nothing points to it. This most commonly happens when you `git add` a file (which creates a blob), but then either modify the file and add it again before committing, or reset/remove the file from the index without committing. The original blob remains in the database but has no references. Unlike dangling commits (which represent lost work from amended or rebased commits), dangling blobs are usually not significant. They're the byproduct of normal Git workflows and represent intermediate file states that were never finalized into a commit. Git's garbage collection will eventually clean them up automatically.
Run git fsck to see all dangling objects in your repository:
git fsckThis will show output like:
dangling blob abc1234567890def
dangling blob 1234567890abcdef
dangling commit fedcba0987654321To see only dangling blobs, use:
git fsck | grep "dangling blob"If you want to see what a dangling blob contains, use git show:
git show <blob-hash>For example:
git show abc1234567890defThis displays the file content stored in that blob. This can help you determine if it contains any important work you forgot to commit.
To save the blob content to a file:
git show abc1234567890def > recovered-file.txtIf you suspect a dangling blob contains important work, use the --lost-found option:
git fsck --lost-foundThis writes dangling objects to the .git/lost-found/ directory:
- Blobs go to .git/lost-found/other/ as files with their content
- Commits go to .git/lost-found/commit/
You can then browse these files to find any lost work:
ls -la .git/lost-found/other/If you've confirmed the dangling blobs aren't needed, you can remove them with garbage collection:
git gcBy default, git gc only removes unreferenced objects older than 2 weeks. To remove them immediately (use with caution):
git gc --prune=nowAfter garbage collection, run fsck again to verify:
git fsckIf you run git fsck regularly and don't want to see dangling object messages, use the --no-dangling option:
git fsck --no-danglingThis runs the integrity check without reporting dangling objects, which speeds up the check and reduces noise.
Note: This doesn't remove dangling objects, it just hides them from the output.
### Dangling Blobs vs Dangling Commits
Dangling blobs represent file content that was staged but never committed. They're usually unimportant intermediate states.
Dangling commits represent actual commits that are no longer reachable—often from git commit --amend, git rebase, or git reset. These are more likely to contain important work.
If you're looking to recover lost work, focus on dangling commits first:
git fsck --lost-found
git log --all --oneline .git/lost-found/commit/*### Git's Safety Period
Git intentionally keeps unreferenced objects for 2 weeks by default. This grace period allows you to recover from mistakes. The setting is controlled by:
git config gc.pruneExpire # default: "2.weeks.ago"### Loose vs Packed Objects
Dangling objects are often "loose" (stored as individual files in .git/objects/). Running git gc packs referenced objects into pack files and removes unreferenced loose objects.
### CI/CD Considerations
If you see dangling blob warnings in CI/CD pipelines or automated repository checks:
1. They're typically not a sign of corruption
2. Running git gc periodically in maintenance jobs can clean them up
3. Use git fsck --no-dangling if you only care about actual corruption
### Large Dangling Blobs
If dangling blobs are taking up significant space (e.g., after accidentally staging large files), you can identify large objects with:
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | sort -k3 -n -r | head -20warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server