Git fsck reports 'dangling commit' when it finds commits not reachable from any branch, tag, or reference. These are normal byproducts of Git operations like rebasing or amending commits and are not harmful.
When you run `git fsck`, Git performs a filesystem consistency check on your repository's object database. A "dangling commit" message indicates that Git found a commit object that exists in the database but isn't reachable from any branch, tag, or other reference. This is not an error or corruption—it's simply Git informing you about orphaned objects. Dangling commits are a normal part of Git's operation and result from everyday actions like: - Running `git commit --amend` (the original commit becomes dangling) - Rebasing branches (old commits become dangling) - Resetting branches with `git reset` - Deleting branches that contained unique commits - Force-pushing changes that rewrote history Git keeps these dangling commits as a safety net, allowing you to recover work if needed. They will eventually be cleaned up automatically by Git's garbage collection (typically after 30 days for unreferenced objects protected by reflog, or 2 weeks for truly dangling objects).
First, recognize that dangling commits are not a problem. They are a safety feature that allows you to recover work. Git reports them during fsck for informational purposes only.
# View dangling commits
git fsck --lost-foundThis will list all dangling objects and also write them to .git/lost-found/ for easy recovery.
To see what a dangling commit contains before deciding what to do with it:
# View the commit details
git show <commit-hash>
# See the commit in context with its parent
git log --oneline -n 5 <commit-hash>Replace <commit-hash> with the hash from the fsck output (e.g., abc1234567890).
If you find a dangling commit contains work you want to keep, you have several options:
Create a new branch pointing to it:
git branch recovered-work <commit-hash>Cherry-pick it onto your current branch:
git cherry-pick <commit-hash>Merge it into your current branch:
git merge <commit-hash>Reset your branch to point to it (destructive to current work):
git reset --hard <commit-hash>If you're looking for a recently lost commit, git reflog is often easier than fsck:
# See all recent HEAD movements
git reflog
# Search reflog for specific text
git reflog | grep "your search term"The reflog shows every position HEAD has been in, including commits that are now dangling. Find the hash and recover as shown in the previous step.
If you're certain you don't need the dangling commits and want to reclaim disk space:
Let Git handle it automatically (recommended):
Git's garbage collection runs automatically and cleans up old dangling objects. No action needed.
Force immediate cleanup:
# Expire reflog entries (makes commits truly dangling)
git reflog expire --expire-unreachable=now --all
# Run garbage collection with aggressive pruning
git gc --prune=nowWarning: After running these commands, dangling commits are permanently deleted and cannot be recovered.
If you simply want to run fsck without seeing dangling object warnings:
# Run fsck without dangling output
git fsck --no-danglingThis performs the same integrity check but doesn't report on unreachable objects, making the output cleaner when you're only interested in actual corruption.
### Dangling Commits vs. Dangling Blobs
Git can report several types of dangling objects:
- Dangling commit: A complete commit not reachable from any reference
- Dangling blob: File content that was staged (git add) but never committed
- Dangling tree: A directory structure without an associated commit
Dangling blobs often come from running git add on files and then modifying them again before committing. Each git add creates a blob object.
### Retention Periods
Git's garbage collection respects these default timeouts:
- gc.reflogExpire: 90 days (commits reachable from reflog are kept)
- gc.reflogExpireUnreachable: 30 days (unreachable reflog entries)
- gc.pruneExpire: 2 weeks (truly dangling objects)
This means most dangling commits are protected for at least 2 weeks, giving you time to recover them.
### Finding All Lost Work
To get a comprehensive list of all dangling commits with their messages:
git fsck --lost-found | grep "dangling commit" | \
awk '{print $3}' | xargs -I {} git log -1 --oneline {}This shows each dangling commit's hash and first line of its commit message.
### CI/CD Considerations
In CI/CD environments, dangling objects typically aren't a concern because:
1. Pipelines usually clone fresh copies of repositories
2. Build agents often use shallow clones (--depth 1)
3. Disk space is reclaimed when the job completes
However, persistent build caches or self-hosted runners with long-lived Git repositories may accumulate dangling objects. Consider running periodic git gc as part of maintenance.
### When Dangling Objects Indicate Problems
While usually harmless, excessive dangling objects can indicate:
- Very aggressive history rewriting
- Failed Git operations that should be investigated
- Disk space issues if the repository has grown unexpectedly large
Check repository size with git count-objects -v and compare the size-pack (compressed) vs size (loose objects) values.
warning: 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