Victor's room

Overview & Root Cause Summary: The error error: inflate: data stream error (incorrect data check) / error: unable to unpack <hash> header / fatal: loose object <hash> (stored in .git/objects/...) is corrupt occurs when Git attempts to decompress and read an object file from the local repository database, but encounters malformed zlib data or an invalid checksum. This almost always results from a sudden power outage, system crash, or forced process termination while Git was actively writing to disk, leaving corrupted or partially written object payloads inside .git/objects/.

Understanding the Root Causes

• Abrupt System Shutdown or Kernel Panic: The machine lost power or experienced a hard reboot while Git was committing, rebasing, or writing zlib-compressed loose objects to disk.
• Interrupted Write or Garbage Collection: Forcefully killing a terminal session (e.g., kill -9) or disconnecting an external drive during an active git commit, git checkout, or git gc process.
• Storage Medium Bit-Rot: Bad disk sectors, failing storage controllers, or filesystem corruption altering bytes in Git’s object store.
• Antivirus or Sync Daemon Interference: Third-party disk cleaners, antivirus scanners, or cloud-sync tools (Dropbox, OneDrive) modifying or truncating internal Git dotfiles.

Step 1: Quick Fix (Isolate the Corrupt Object and Audit Repository)

Pinpoint the exact corrupted object hash using Git’s filesystem check and quarantine the corrupted file outside the repository.

# 1. Run a full repository consistency check to identify the corrupt object hash:
git fsck --full

# 2. Locate and backup the corrupt loose object file:
# Example: if hash is 3a5b6c..., path is .git/objects/3a/5b6c...
mkdir -p /tmp/git-quarantine
mv .git/objects/<first-2-chars>/<remaining-chars> /tmp/git-quarantine/

# 3. Check what missing object git fsck reports now that the corrupted file is removed:
git fsck --full

Step 2: Recovering Objects Already Pushed to Remote (GitHub / GitLab)

If the corrupted commit, tree, or file blob already exists on your remote repository, download a clean copy directly over the wire.

# 1. Fetch missing objects cleanly from the remote repository:
git fetch origin

# 2. If git fetch refuses to download an isolated missing object, fetch with prune:
git fetch origin --prune --tags

# 3. Unpack any fetched packfiles into loose objects if necessary:
git unpack-objects < .git/objects/pack/*.pack 2>/dev/null || true

Step 3: Reconstructing Local Blobs and Recovering Commits from Reflog

If the corrupted object was a newly created local file blob or unpushed commit, re-create the object directly from your working tree or reflog history.

# Option A: If the missing object is a file blob, re-hash it from your working tree:
git hash-object -w path/to/corrupted-file.ext

# Option B: If the missing object is a commit, find the previous commit hash in reflog:
tail -n 10 .git/logs/HEAD

# Re-point your branch to the last known healthy commit:
git update-ref HEAD <valid_commit_hash>

# Option C: Rebuild the staging index if the index cache was also damaged:
rm -f .git/index
git reset

Verification & Testing Steps

Confirm that Git’s object database passes full consistency checks without any corrupt or dangling errors.

# 1. Verify complete repository integrity (should output clean status):
git fsck --full

# 2. Test reading recent commit history:
git log --oneline -n 5

# 3. Verify working directory status:
git status

Summary Comparison Table

Corrupted Object Type	Diagnostic Symptom	Recovery Strategy	Data Loss Risk
Remote Object	Object exists on GitHub/GitLab	Quarantine corrupt file & git fetch origin	Zero (Downloaded from remote)
Local File Blob	Unpacked blob checksum error	git hash-object -w <file>	Zero if file exists on disk
Commit Object	bad object HEAD / commit error	Recover commit SHA from .git/logs/HEAD	Minimal (Recovers latest reflog state)
Staging Index	bad signature / index corrupt	rm -f .git/index && git reset	None (Reconstructs from commit tree)