Git Repository Integrity: Verify with git fsck

Advanced

What git fsck checks

`git fsck` checks the integrity of Git's object database: it verifies object sanity and traces connectivity from the heads Git considers reachable. With no explicit object arguments, Git uses the index, refs under `refs`, and reflogs as heads unless you change those rules. A clean run normally prints nothing.

git fsck
git fsck --full
git fsck --strict

?

Reachability is not the same as corruption

An object can be valid but unreachable. For example, deleting a branch can leave its former commits and their supporting trees/blobs temporarily present in the object database. `git fsck --unreachable` reports objects that exist but are not reachable from the selected heads. `--dangling` reports objects that are not directly referenced, which is a different category.

git fsck --unreachable
git fsck --unreachable --no-reflogs
git fsck --dangling

Reflogs matter here: by default, reflog entries can keep otherwise-unreferenced commits reachable for fsck's traversal. `--no-reflogs` removes those reflog entries from the set of heads, making it useful when investigating commits that disappeared from refs but may still be named by a reflog.

?

Connectivity-only checks

`--connectivity-only` focuses on whether reachable objects point to objects that are present, avoiding the full blob-content checks. It is useful when connectivity is the question and a faster check is appropriate. It does not mean that all object-format or blob-level integrity checks have been performed.

git fsck --connectivity-only
git fsck --connectivity-only --no-dangling

?

Roots, references, and names

Use `--root` to report root nodes and `--tags` to treat tags as heads for reachability. `--name-objects` supplements object IDs with names describing how reachable objects can be reached, such as a ref or revision expression. The references database is checked by default in current Git; this lesson does not teach the newer explicit `--references` switch because the local Git 2.47.3 verifier does not accept that option.

git fsck --root
git fsck --tags
git fsck --name-objects

?

Strict checking and serious findings

`--strict` enables additional checks, including detection of certain legacy file-mode anomalies. A dangling or unreachable object is not automatically evidence of corruption; a missing object or hash mismatch is materially different. Treat fsck output as a diagnostic report and investigate the repository state before deleting anything.

git fsck --strict
git fsck --full --strict --no-dangling

?

A safe investigation workflow

Start with the least surprising inspection: run `git fsck` and capture its output. If you are investigating reachability, compare the default result with `--no-reflogs` and, when useful, `--name-objects`. Use `--connectivity-only` when you specifically need a connectivity-focused check. Use `--strict` when you want the additional integrity checks documented by Git. Keep the original repository intact while investigating.

git fsck > fsck-report.txt
git fsck --unreachable --no-reflogs --name-objects > fsck-reachability.txt
git fsck --full --strict --no-dangling > fsck-strict.txt

Practice what you learned

Use the dedicated Git code-completion exercise for this lesson.

Official source boundary

This lesson uses the official Git `git-fsck` documentation and the official Git 2.56.0 command documentation for object-integrity semantics. No third-party documentation is used for Git command semantics.