Chapter 7.7 — git fsck — Repair Corrupted Repo☕ 12 min read

git fsck — Repair Corrupted Repo

Dangling = normal. Missing/Corrupt = serious. Fsck se samjho, phir ilaaj karo.

01What is git fsck — The Repository Doctor

git fsck stands for File System Consistency Check — it verifies the integrity of your Git repository.

Git stores everything as objects with SHA-1 hashes. git fsck checks that all objects are valid, properly referenced, and not corrupted.

It detects four types of issues:

Dangling objects — objects that exist in .git/objects but are not referenced by any branch, tag, or reflog entry.
Missing objects — objects that should exist (referenced by a commit) but are not in .git/objects.
Corrupted objects — objects whose content does not match their SHA-1 hash (data corruption).
Broken links — a tree points to a blob, or a commit points to a tree, but the target does not exist.

When to run git fsck: Git errors about corrupt objects, missing blobs, weird behavior, after disk failures, after crashes during git operations.

# Basic fsck — check repository health
git fsck

# Common output (normal repo):
# dangling commit a1b2c3d4...
# dangling blob e5f6g7h8...
# These are normal! Usually from amend, rebase, reset.

# Problem output:
# error: object file .git/objects/ab/c1234 is corrupt
# missing blob e5f6g7h8...
# broken link from tree abc123...

# Full check — more thorough
git fsck --full

# Check without reflog (find truly orphaned objects)
git fsck --no-reflogs

02Understanding Dangling Objects

A dangling commit is a commit not reachable from any branch or tag. Created by: git commit --amend, git rebase, git reset, branch deletion.

A dangling blob is file content not referenced by any tree or commit. Created by: git add without commit, partial resets.

Dangling objects are NORMAL — every git commit --amend creates one. They are NOT errors.

They exist because Git is conservative — it does not immediately delete old objects after amend or rebase.

Git's garbage collector (git gc) eventually removes dangling objects older than 2 weeks.

You can RECOVER dangling commits! They still contain real data. Use git show with the hash or git checkout with the hash.

If you accidentally reset or amend, check git fsck for dangling commits — they might be your lost work.

# Create a dangling commit (accidental reset)
echo "important work" > file.txt
git add . && git commit -m "important"

# Oops, accidental hard reset
git reset --hard HEAD~1

# Check fsck — the commit still exists!
git fsck
# dangling commit abc1234...

# Inspect the dangling commit
git show abc1234
# commit abc1234
# Author: You
#     important

# Recover it!
git branch recovered-work abc1234
# Or: git cherry-pick abc1234

# Dangling blobs — less useful, but checkable
git fsck | grep "dangling blob"
# dangling blob def5678...
git cat-file -p def5678
# Shows the file content that was staged but never committed

03Handling Corrupted Objects

Corrupted objects are SERIOUS — the file content does not match its SHA-1 hash.

Causes: disk errors, power failure during write, accidental .git/objects/ file modification, filesystem corruption.

Symptom: error: object file .git/objects/xx/yyyy is corrupt or fatal: bad object HEAD.

Recovery depends on what is corrupted:

If BLOB corrupted: restore from remote (git fetch origin), or find the file in a backup.
If TREE corrupted: harder — you need the exact directory structure from another clone.
If COMMIT corrupted: if pushed to remote, git fetch can restore it.

Nuclear option: re-clone from remote. Loses unpushed commits but gives a clean repository.

Prevention: use UPS, do not manually edit .git/objects/, ensure disk is healthy.

# Step 1: Identify the corruption
git fsck --full
# error: object file .git/objects/ab/c1234 is corrupt

# Step 2: Try fetching from remote
git fetch --all
# If the object was pushed, Git restores it!

# Step 3: If fetch does not help, check the specific object
git cat-file -t ab1234
# If this fails, the object is truly corrupt

# Step 4: Remove the corrupt file and re-fetch
rm .git/objects/ab/c1234...
git fetch --all

# Step 5: Nuclear — re-clone if nothing works
cd ..
git clone <remote-url> repo-fresh
cd repo-fresh
# You lose unpushed commits but get a clean repo

💡 Pro Tip: If git fsck reports corrupted objects, your FIRST action should be to try fetching from the remote. If the corrupted object exists on the remote (it was pushed), Git can replace the local corrupted copy. Run git fetch --all before attempting manual recovery. This is why pushing regularly is important — pushed commits have a remote backup.

04Missing Objects and Broken Links

Missing objects = a commit, tree, or blob is referenced but does not exist in .git/objects/.

Broken links = a tree points to a blob, or a commit points to a tree, but the target does not exist.

This is worse than dangling — a dangling object is extra (not referenced). A missing object is a HOLE in the chain.

Causes: interrupted git operations, manual deletion of .git/objects/ files, disk space issues.

Recovery: if the object exists on a remote, git fetch restores it. If only local, check reflog or other branches.

git fsck --full --no-reflogs — thorough check that ignores reflog entries (which might reference missing objects).

# Check for missing objects
git fsck --full
# missing blob abc1234...
# missing tree def5678...
# broken link from tree xyz9876 to blob abc1234

# Step 1: Try fetching from remote
git fetch --all
# If remote has the objects, they will be downloaded

# Step 2: Check if any branch has the object
git fsck --unreachable
# Lists all unreachable objects that still exist

# Step 3: For missing blobs — check if the file still exists
# The blob is just file content. If you have the file:
echo "file content here" > recovered.txt
git hash-object -w recovered.txt
# If hash matches the missing blob, it is restored!

# Step 4: Nuclear option — re-clone
# If nothing works and you have a remote:
cd ..
git clone <remote-url> repo-fresh
cd repo-fresh
# You lose unpushed commits but get a clean repo

05Prevention and Regular Maintenance

Most repository corruption is preventable with good practices.

Push regularly — remote is your backup. If local corrupts, remote has the objects.

Do not manually edit files in .git/objects/ — this is the #1 cause of corruption.

Use git gc periodically — it optimizes storage and cleans up dangling objects.

git repack -a -d — repack all objects into a single packfile for efficiency.

git prune — remove unreachable objects immediately (normally done by gc).

If your disk is failing, Git corruption is a symptom. Run disk diagnostics.

git fsck before important operations (like force push or rebase) can catch problems early.

# Regular maintenance routine
git gc                  # Clean up and optimize
git repack -a -d       # Repack everything tightly
git prune               # Remove loose unreachable objects
git count-objects -v    # Check repo size and object count

# Before important operations
git fsck                # Quick health check
git fsck --full         # Thorough check

# After disk issues or crashes
git fsck --full --no-reflogs  # Deep integrity check

The most common cause of Git corruption is not disk failure — it is developers manually editing or deleting files in .git/objects/ or .git/refs/. Never touch the .git directory internals manually unless you absolutely know what you are doing. If Git tells you there is a problem, use Git commands to fix it, not your file manager.

Lo kar liya — Key Points:

✅ git fsck verifies the integrity of your Git repository — checks objects, references, and links
✅ Dangling objects are NORMAL — created by amend, rebase, reset. They are not errors and can be recovered
✅ Corrupted objects are SERIOUS — content doesn't match SHA-1 hash. Try fetching from remote to repair
✅ Missing objects are holes in the data — referenced but not present. Fetch from remote or re-clone
✅ Most corruption comes from manually editing .git/objects/ files — never do this
✅ Push regularly — remote is your backup for corrupted or missing objects
✅ Run git gc periodically to clean up dangling objects and optimize storage
✅ git fsck --full --no-reflogs gives the most thorough check, ignoring reflog entries

Previous7.6 — git clean — Remove Untracked 📋 All Chapters Next Chapter8.1 — What are Git Hooks →