How to fix error: sha1 mismatch for ./objects/ab/cdef in Git

GitADVANCEDHIGHUpdated Dec 6, 2025· 169 views

This error indicates repository corruption where an object file's content doesn't match its SHA-1 hash filename. Recovery typically involves replacing corrupt objects from a backup or recloning the repository.

Quick fix

Fixes error: sha1 mismatch for ./objects/ab/cdef

git fsck --full
  1. Run git fsck to identify all corrupt objects
  2. Determine what the corrupt object contains
  3. Recover objects from a remote repository
  4. Recover objects from a backup or another clone
git — error
git fsck --full
error: sha1 mismatch for ./objects/ab/cdef

What this error means

The "sha1 mismatch" error occurs when Git's `git fsck` command detects that a stored object's content doesn't match the SHA-1 hash used as its filename. Git stores objects (commits, trees, blobs) in the `.git/objects` directory, with filenames derived from the SHA-1 hash of their content. When you see this error, it means the object file has been corrupted - the bytes on disk no longer hash to the expected value. This can happen due to disk failures, filesystem errors, interrupted writes, or bit rot. The error message shows the expected hash and indicates which object directory contains the corrupt file. This is a serious data integrity issue. While Git's content-addressable storage makes corruption detectable, the corrupt object may contain irreplaceable data like a commit, file content, or directory structure. Recovery depends on having access to the same object from another source (a backup, remote, or another clone).

Typical symptoms

  • git fsck reports 'error: sha1 mismatch' with specific object paths
  • git pull, push, or clone operations fail with object errors
  • Commands that read objects (git log, git show, git diff) fail for affected commits
  • Repository operations hang or produce unexpected errors
  • Error messages like 'object corrupt or missing' appear
  • Random git operations fail unpredictably

Common causes

  1. Disk hardware failure or bad sectors corrupting object files
  2. Filesystem corruption or journaling failures during write operations
  3. Interrupted git operations (power loss, kill) during object writes
  4. Memory errors (RAM issues) causing corrupted writes to disk
  5. Network filesystem (NFS, CIFS) synchronization or cache issues
  6. Bit rot causing gradual data corruption on storage media
  7. Antivirus or backup software modifying object files
  8. Disk full during object packing or garbage collection

How to fix "error: sha1 mismatch for ./objects/ab/cdef"

1Run git fsck to identify all corrupt objects

First, run a full repository check to identify all corrupted objects:

bash
git fsck --full

This command will list all problematic objects. Note down the full SHA-1 hashes of corrupt objects. The output will look like:

bash
error: sha1 mismatch 87859f196ec9266badac7b2b03e3397e398cdb18
error: object corrupt or missing: 87859f196ec9266badac7b2b03e3397e398cdb18

Also check for dangling objects and broken links:

bash
git fsck --lost-found

This will recover any orphaned objects to .git/lost-found/.

2Determine what the corrupt object contains

Before attempting recovery, understand what data is affected:

bash
# Try to determine the object type (may fail if severely corrupt)
git cat-file -t <sha1>

# If readable, view the object content
git cat-file -p <sha1>

If these commands fail, check if any refs point to this object:

bash
# See if it's a commit in any branch
git branch --contains <sha1> 2>/dev/null

# Check the reflog for references
git reflog | grep <sha1_prefix>

Knowing whether the corrupt object is a commit, tree, or blob helps determine recovery options.

3Recover objects from a remote repository

If you have a remote with the same commits, you can often recover missing objects:

bash
# Fetch all objects from remote
git fetch origin

# Force fetch specific branch if needed
git fetch origin main:refs/remotes/origin/main

After fetching, run fsck again:

bash
git fsck --full

If the remote has the same object, Git will replace the corrupt local version during fetch. This is the cleanest recovery method when available.

4Recover objects from a backup or another clone

If you have another clone of the repository or a backup:

bash
# From another clone, copy the missing object
# Objects are stored at .git/objects/XX/YYYYYY...
# where XX is the first 2 chars of the SHA-1

# Example: for object 87859f196ec9266badac7b2b03e3397e398cdb18
# Copy from backup_repo/.git/objects/87/859f196ec9266badac7b2b03e3397e398cdb18
# to corrupt_repo/.git/objects/87/859f196ec9266badac7b2b03e3397e398cdb18

cp /path/to/backup/.git/objects/87/859f196ec9... .git/objects/87/

Alternatively, use git to copy objects:

bash
# Add the backup as a remote and fetch
git remote add backup /path/to/backup/repo
git fetch backup
5Recreate blob objects from working files

If the corrupt object is a blob (file content), and you have the original file:

bash
# Recreate the blob object
git hash-object -w /path/to/original/file

This creates a new blob object with the file's content. The SHA-1 must match what Git expects. If you don't have the exact file content, this won't work.

For files still in your working directory:

bash
# Check if the file exists and matches what Git expects
git status
git diff

If files exist but aren't tracked correctly, you may need to re-add them:

bash
git add <file>
git commit -m "Recover after corruption"
6Remove corrupt objects and reclone if recovery fails

If objects cannot be recovered, you may need to start fresh:

bash
# Save any local changes first
git stash

# Or copy uncommitted files to a safe location
cp -r * /path/to/backup/

# Reclone the repository
cd ..
rm -rf corrupt_repo
git clone <remote_url> repo

# Restore any local changes
cp -r /path/to/backup/* repo/

If you have local commits not pushed to remote:

bash
# Try to export patches first (may fail for corrupt commits)
git format-patch origin/main

# Apply patches in new clone
git am *.patch
7Verify disk and filesystem health

After recovery, investigate the root cause:

bash
# Check disk health (Linux)
sudo smartctl -a /dev/sda

# Check filesystem for errors
sudo fsck -n /dev/sda1

# Check system logs for disk errors
dmesg | grep -i "error\|fail\|bad"
journalctl -k | grep -i disk

For memory issues:

bash
# Run memory test (requires reboot)
sudo memtest86+

Consider enabling Git's built-in transfer integrity checking:

bash
git config --global transfer.fsckObjects true
git config --global receive.fsckObjects true
git config --global fetch.fsckObjects true

This validates objects during fetch/push/receive operations.

Advanced notes

Understanding Git's Object Storage: Git stores objects in .git/objects using content-addressable storage. The SHA-1 hash is computed from the object content plus a header. Loose objects are stored in .git/objects/XX/YYYY... while packed objects are in .git/objects/pack/. SHA-1 mismatches in pack files show additional errors like "index CRC mismatch" or "inflate: data stream error".

Pack File Corruption: If corruption is in a pack file, you may see different errors:

bash
error: SHA1 checksum mismatch for ./objects/pack/pack-xxx.pack
fatal: index file corrupt

Try repacking or unpacking:

bash
# Unpack all pack files
git unpack-objects < .git/objects/pack/pack-xxx.pack

# Or repack everything
git repack -a -d

Git's fsck.skipList: For known corrupt objects you want to ignore (use with caution):

bash
# Create a file with SHA-1s to skip
echo "87859f196ec9266badac7b2b03e3397e398cdb18" > .git/skip-list
git config fsck.skipList .git/skip-list

Network Filesystem Considerations: NFS and CIFS can cause corruption due to caching and synchronization issues. Consider using core.fsyncObjectFiles:

bash
git config core.fsyncObjectFiles true

Preventing Future Corruption:
- Enable object verification: git config transfer.fsckObjects true
- Use reliable storage with ECC memory
- Maintain regular backups and multiple remotes
- Run periodic git fsck as part of maintenance
- Consider using Git's built-in maintenance: git maintenance start

SHA-256 Transition: Git is transitioning from SHA-1 to SHA-256. Future versions will use SHA-256 for object naming, which provides better collision resistance and integrity checking.

Frequently asked questions

What does "error: sha1 mismatch for ./objects/ab/cdef" mean?
The "sha1 mismatch" error occurs when Git's git fsck command detects that a stored object's content doesn't match the SHA-1 hash used as its filename. git/objects directory, with filenames derived from the SHA-1 hash of their content. When you see this error, it means the object file has been corrupted - the bytes on disk no longer hash to the expected value.
How do I fix "error: sha1 mismatch for ./objects/ab/cdef"?
This error indicates repository corruption where an object file's content doesn't match its SHA-1 hash filename. Recovery typically involves replacing corrupt objects from a backup or recloning the repository.
What causes "error: sha1 mismatch for ./objects/ab/cdef"?
Disk hardware failure or bad sectors corrupting object files Filesystem corruption or journaling failures during write operations Interrupted git operations (power loss, kill) during object writes
Is the "error: sha1 mismatch for ./objects/ab/cdef" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading