# git fsck --unreachable: Find Dangling Objects

> git fsck checks object integrity and lists dangling/unreachable commits you can recover. Reference for --unreachable, --lost-found, and repo-corruption errors in CI.

Source: https://latchkey.dev/learn/command-reference/git-fsck-unreachable  
Updated: 2026-06-30

git fsck verifies the integrity of the object database and reports dangling and unreachable objects, which is how you recover commits the reflog has already dropped.

When a clone or fetch in CI leaves a corrupt object, or work was lost beyond the reflog, fsck is the diagnostic. It validates every object and points you at dangling commits you can still rescue.

## What it does

git fsck walks the object store, checking connectivity and integrity, and reports objects that are dangling (not referenced) or unreachable (not reachable from any ref). --lost-found writes dangling commits/blobs into .git/lost-found so you can inspect and recover them. It is read-only by default; it does not delete anything.

## Common usage

```Terminal
git fsck --full
# show unreachable objects (candidates for recovery)
git fsck --unreachable
# dump dangling objects to .git/lost-found
git fsck --lost-found
# recover a dangling commit
git show <dangling-sha>
git branch recovered <dangling-sha>
```

## Options

| Flag | What it does |
| --- | --- |
| --full | Check all object directories, including alternates and packs |
| --unreachable | Print objects not reachable from any ref |
| --dangling / --no-dangling | Show or hide dangling objects (shown by default) |
| --lost-found | Write dangling objects into .git/lost-found |
| --connectivity-only | Skip per-object checks; only verify reachability (faster) |
| --strict | Apply stricter validity checks |

## In CI

A failed fetch with "early EOF" or "did not receive expected object" often leaves a repo that fsck flags as corrupt; on CI it is usually cheaper to delete the clone and re-fetch than to repair. After git gc --prune=now, fsck shows fewer unreachable objects because they were reclaimed. Use --connectivity-only for a fast sanity check on large repos.

## Common errors in CI

"error: object file ... is empty" or "fatal: loose object <sha> is corrupt" means a damaged object, frequently from an interrupted fetch; re-clone. "missing blob/tree <sha>" indicates a broken pack. "dangling commit <sha>" is informational: it is recoverable, not an error.

## Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

```.github/workflows/ci.yml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached
```

> `git rev-parse --abbrev-ref HEAD` returns the literal string `HEAD` on a detached checkout rather than a branch name. On GitHub Actions read `github.ref_name` instead; the git command cannot know what it was checked out for.

## FAQ

### git fsck --unreachable: Find Dangling Objects?

When a clone or fetch in CI leaves a corrupt object, or work was lost beyond the reflog, fsck is the diagnostic. It validates every object and points you at dangling commits you can still rescue.

### What it does?

git fsck walks the object store, checking connectivity and integrity, and reports objects that are dangling (not referenced) or unreachable (not reachable from any ref). --lost-found writes dangling commits/blobs into .git/lost-found so you can inspect and recover them. It is read-only by default; it does not delete anything.

### In CI?

A failed fetch with "early EOF" or "did not receive expected object" often leaves a repo that fsck flags as corrupt; on CI it is usually cheaper to delete the clone and re-fetch than to repair. After git gc --prune=now, fsck shows fewer unreachable objects because they were reclaimed.

### Common errors in CI?

"error: object file ... is empty" or "fatal: loose object <sha> is corrupt" means a damaged object, frequently from an interrupted fetch; re-clone. "missing blob/tree <sha>" indicates a broken pack. "dangling commit <sha>" is informational: it is recoverable, not an error.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt