This error occurs when Git cannot locate or read an object file in its internal database. The fix involves verifying repository integrity, recovering missing objects from remotes or backups, or re-cloning the repository.
The "unable to read sha1 file" error in Git indicates that the repository's object database is corrupted or incomplete. Git stores all content (files, commits, trees) as objects in the `.git/objects` directory, each identified by a unique SHA-1 hash. When Git references an object that should exist but cannot be found or read, this error appears. Git's object storage works by computing a 40-character SHA-1 hash of each piece of content (with a header indicating type and size). The first two characters of this hash form a subdirectory name under `.git/objects`, and the remaining 38 characters become the filename. For example, an object with hash `b7e23ec29af22b0b4e41da31e868d57226121c84` is stored at `.git/objects/b7/e23ec29af22b0b4e41da31e868d57226121c84`. When this error occurs, it typically means either the object file is missing entirely, the file exists but is corrupted (0 bytes or invalid content), or the object reference in a tree or commit points to a non-existent SHA-1. This can happen after disk failures, interrupted Git operations, filesystem corruption, or issues with partial/shallow clones.
First, identify the extent of the corruption by running Git's file system check:
git fsck --fullThis will report all corrupted, missing, or dangling objects. Common output includes:
- broken link from tree <sha1> to blob <sha1> - a tree references a missing file
- missing blob <sha1> - a file object is missing
- invalid sha1 pointer - a reference points to nothing
For more detail about which files are affected:
git fsck --full --name-objectsIf you have a remote repository (GitHub, GitLab, etc.), Git may be able to recover the missing objects:
git fetch --allOr fetch with full depth if you have a shallow clone:
git fetch --unshallowAfter fetching, run git fsck --full again to check if the issue is resolved.
Sometimes Git creates 0-byte object files that block operations. Find and remove them:
# Find empty files in .git/objects (Linux/macOS)
find .git/objects -type f -size 0
# Remove empty files (verify the list first!)
find .git/objects -type f -size 0 -deleteAfter removing empty files, fetch from remote again:
git fetch originThis allows Git to re-download the missing objects.
If you have a backup of the repository or another working clone, you can extract the missing objects:
From a packed backup:
# In the backup repository
git cat-file blob <missing-sha1> > recovered-file.dat
# In the damaged repository
git hash-object -w recovered-file.datCopy objects directly:
# Copy missing object from backup (adjust path based on SHA-1)
# For sha1 = abc123..., copy from .git/objects/ab/c123...
cp /path/to/backup/.git/objects/ab/c123... .git/objects/ab/If the corruption is in the index (staging area) rather than the objects, reset it:
# Remove the index file
rm .git/index
# Rebuild it from HEAD
git reset HEADFor cache-tree corruption specifically:
git update-index --refreshIf the corruption is severe, the safest approach is to clone fresh and copy your work:
# Clone the repository fresh
git clone <remote-url> fresh-repo
# Copy your uncommitted changes (excluding .git)
rsync -av --exclude='.git' ./damaged-repo/ ./fresh-repo/
# Or manually copy changed files
cp -r src/ fresh-repo/src/Then use the fresh repository going forward and verify with git status.
The git-repair tool can automatically fix many types of repository corruption:
Install git-repair:
# Debian/Ubuntu
sudo apt install git-repair
# macOS with Homebrew
brew install git-repairRun the repair:
git-repairThis tool will attempt to fetch missing objects from remotes and repair references automatically.
After recovery, confirm the repository is fully functional:
# Full integrity check
git fsck --full
# Test common operations
git status
git log --oneline -10
git branch -aIf git fsck reports no errors, the repository has been successfully repaired.
Understanding Git's object storage: Git stores four types of objects: blobs (file contents), trees (directory listings), commits, and tags. Each object is compressed with zlib and named by its SHA-1 hash. When Git cannot read an object, it means the file at .git/objects/XX/XXXXXXXX... is missing, empty, or corrupted.
Packed objects: Over time, Git packs loose objects into .git/objects/pack/*.pack files for efficiency. If corruption is in a pack file, you may need to repack after recovery:
git repack -a -dPartial and shallow clones: These intentionally omit objects to save space. If you encounter this error with a shallow clone, converting to a full clone usually resolves it:
git fetch --unshallowPreventing future corruption:
- Avoid interrupting Git operations (especially during gc, repack, or fetch)
- Use a reliable filesystem with journaling (ext4, APFS, NTFS)
- Keep backups of important repositories
- Run git fsck periodically to catch issues early
- If using network drives, ensure stable connections during Git operations
CI/CD cached clones: In CI environments, cached Git directories can become corrupted over time. If this error appears in CI, clearing the cache or using a fresh clone typically resolves it.
fatal: bad object in rev-list input
Git rev-list encounters bad or invalid object
fatal: Out of memory, malloc failed during pack operation
Out of memory during Git pack operation
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server
fatal: unable to access: Proxy auto-configuration failed
How to fix 'Proxy auto-configuration failed' in Git
fatal: unable to access: Authentication failed (proxy requires basic auth)
How to fix 'Authentication failed (proxy requires basic auth)' in Git