Articles

Detect and Repair Git Repository Corruption with fsck (2026)

April 18, 2026 6 min read

The git fsck command doesn’t actually repair repository corruption in the way a traditional fsck repairs filesystem corruption. Instead, it’s a diagnostic tool that detects inconsistencies and identifies the objects that are broken. True repair often involves more drastic measures or understanding that the repository might be irrecoverably damaged.

Let’s say you’re trying to push a commit, and you get an error like:

error: inflate: data stream error (incorrect data check)
error: sha1 mismatch (e7d3223...): bad
fatal: object e7d3223... is corrupted

This means Git, when trying to read a specific object (identified by its SHA-1 hash e7d3223...), encountered an error during decompression or data integrity verification. The sha1 mismatch part indicates that the calculated checksum of the decompressed data doesn’t match the expected checksum stored in the object’s header, proving it’s been corrupted.

Here’s what’s actually happening at a system level: Git stores all your repository’s data (commits, trees, blobs, tags) as individual files in the .git/objects/ directory, named by their SHA-1 hash. When Git needs to access an object, it reads this file, decompresses it (if it’s compressed, which most are), and verifies its integrity using the checksum embedded within the file. Corruption occurs when the file’s content gets altered in a way that makes it unreadable or its checksum invalid, often due to disk errors, interrupted writes, or faulty hardware.

Here are the common causes and how to diagnose/fix them:

1. Filesystem Corruption:

  • Diagnosis: This is the most common culprit. The underlying filesystem on your disk might have errors.
    • Command: Run your operating system’s disk checking utility.
      • On Linux: sudo fsck /dev/sdXY (replace /dev/sdXY with your partition).
      • On macOS: diskutil repairDisk /dev/diskX (replace /dev/diskX with your disk identifier).
      • On Windows: chkdsk C: /f /r (replace C: with your drive letter).
    • Fix: Follow the prompts to repair the filesystem. This might involve rebooting your system.
    • Why it works: This directly addresses the root cause if the corruption is due to the storage medium’s integrity. Git relies on the filesystem to store its objects correctly.

2. Interrupted Git Operations:

  • Diagnosis: If a Git command (like git gc, git clone, git pull, git push) was interrupted by a power outage, system crash, or manual termination while writing objects, it can leave incomplete or corrupted files.
    • Command: Run git fsck --full --no-reflogs in your repository. Look for messages like "dangling blob" or "dangling commit" that don’t seem to belong, or "sha1 mismatch" errors.
    • Fix: If git fsck reports specific corrupted objects, and they are not referenced by any branch or tag (i.e., they are "dangling"), you can often clean them up.
      • Command: git prune --expire now followed by git gc --prune=now.
      • Why it works: git prune removes unreachable objects, and git gc reorganizes the object database, potentially discarding the corrupted, unreferenced objects.

3. Disk Hardware Issues:

  • Diagnosis: Faulty RAM, a failing hard drive, or bad sectors can lead to data corruption.
    • Command: Check your system’s SMART status for your hard drive.
      • On Linux: sudo smartctl -a /dev/sdX (replace /dev/sdX with your drive).
      • On macOS: Use Disk Utility’s "S.M.A.R.T. Status" or a third-party tool.
      • On Windows: Use wmic diskdrive get status or third-party tools.
    • Fix: Replace the failing hardware. This is the only real fix.
    • Why it works: Git can only work with data that is accurately read from and written to the storage medium. If the medium itself is faulty, data will become corrupted.

4. Antivirus or Backup Software Interference:

  • Diagnosis: Occasionally, aggressive real-time scanning or backup processes might lock or partially overwrite Git object files while Git is trying to access or write them.
    • Command: Temporarily disable real-time scanning for your repository’s directory and observe if the errors persist.
    • Fix: Configure your antivirus or backup software to exclude your Git repository directories (.git/objects/, .git/index, etc.) from active scanning or real-time protection.
    • Why it works: This prevents external software from interfering with Git’s file operations, ensuring Git has exclusive access when it needs it.

5. Network Issues During Clone/Fetch/Push (for distributed corruption):

  • Diagnosis: If corruption occurs during a network transfer, it might be that a specific object was corrupted before it was sent, or during transit.
    • Command: If the corruption is in a remote repository that you’re cloning from or fetching from, git fsck on your local copy might show the error. To confirm, try cloning the repository on a different machine or network.
    • Fix: If the corruption is confirmed to be in the remote repository, you’ll need to ask the owner of that repository to fix it. This often involves finding a known good backup or re-creating the repository from a clean state. If the corruption happened during transit, it’s harder to pinpoint but usually points back to network instability or faulty hardware on either end.
    • Why it works: This helps isolate whether the problem is with your local copy, your network, or the source repository itself.

6. Git Index Corruption:

  • Diagnosis: While git fsck primarily checks the object database, a corrupted index (.git/index) can sometimes manifest as strange behavior or errors during operations that involve staging.
    • Command: git fsck --full --no-reflogs. If the errors are less about object integrity and more about "missing tree" or "bad index" (though fsck is less direct here), consider the index.
    • Fix: Remove and recreate the index.
      • Command: rm .git/index followed by git reset.
      • Why it works: This discards the potentially corrupted index file and rebuilds it from the current working directory and HEAD, effectively starting the staging area fresh.

If git fsck reports specific corrupted objects and they are referenced by branches or tags, you’re in a tougher spot. You might need to:

  • Fetch from another clone: If you have another local clone of the same repository, try fetching from it: git fetch /path/to/other/clone.
  • Recover from backups: If you have a backup of the repository, restore it.
  • Re-clone: If it’s a remote repository, the safest bet is often to back up any unpushed local changes, delete your local repository, and re-clone it from the remote.

The next error you’ll hit after fixing repository corruption is often related to fetching or pushing again, as the original operation was interrupted. You might see error: RPC failed; curl 56 Recv failure: Connection reset by peer if the connection was unstable, or simply be able to proceed if the corruption was the sole issue.

Want structured learning?

Take the full Git course →