How to fix fatal: bad object in rev-list input in Git

GitADVANCEDHIGHUpdated Dec 2, 2025· 160 views

This error occurs when git rev-list encounters a missing, corrupted, or invalid object (commit, blob, or tree) in the repository. It typically indicates repository corruption or incomplete data transfer.

Quick fix

Fixes fatal: bad object in rev-list input

git fsck --full --strict
  1. Verify the extent of corruption with git fsck
  2. Try fetching missing objects from remote
  3. Restore objects from a backup or alternate repository
  4. Fix corrupt branch references
git — error
git fsck --full --strict
fatal: bad object in rev-list input

What this error means

The git rev-list command is used internally by Git to list commit objects in reverse chronological order. When it encounters a "bad object" or "invalid object" error, it means Git is trying to access an object (commit, tree, or blob) that is either missing from the object database, corrupted, or has an invalid SHA-1 hash. This error commonly appears during operations like git push, git fetch, git clone, or git log when Git needs to traverse the commit history. The object database in .git/objects stores all repository data, and when objects are missing or corrupted, Git cannot complete operations that need to read those objects. Repository corruption can occur due to incomplete clone/fetch operations, interrupted push/pull transfers, filesystem errors, disk corruption, aggressive garbage collection, or cloud sync conflicts (OneDrive, iCloud). Force pushes with Git LFS can also trigger this error if objects aren't properly synchronized.

Typical symptoms

  • Git commands fail with "fatal: bad object" followed by a commit hash
  • git rev-list exits with status 128
  • Push or fetch operations fail with "error: bad object" messages
  • git log or git status shows "invalid object" errors
  • git fsck reports missing blobs, trees, or commits
  • Repository operations work on remote but fail locally
  • CI/CD pipelines fail when accessing repository history

Common causes

  1. Incomplete git clone, fetch, or pull operation that was interrupted
  2. Force push to remote when local copy lacks objects the remote references
  3. Repository stored in cloud-synced folder (OneDrive, iCloud, Dropbox) causing file conflicts
  4. Filesystem corruption or disk errors damaging .git/objects files
  5. Aggressive or interrupted git gc (garbage collection) removing referenced objects
  6. Corrupt branch references pointing to non-existent commits
  7. Using commit hash from wrong repository (copy-paste error)
  8. Manual modification or deletion of files in .git/objects directory
  9. Power loss or system crash during git operation
  10. Network errors during clone leaving incomplete pack files

How to fix "fatal: bad object in rev-list input"

1Verify the extent of corruption with git fsck

Run a full filesystem check to identify all missing or corrupt objects:

bash
git fsck --full --strict

This will output all integrity issues. Note the object types (blob, tree, commit) and their hashes. If you see "missing blob", "missing tree", or "dangling commit", the repository has lost data.

For detailed output:

bash
git fsck --full --strict --verbose
2Try fetching missing objects from remote

If you have a remote repository (origin), attempt to fetch the missing objects:

bash
# Remove empty object files that may cause issues
find .git/objects/ -type f -empty -delete

# Fetch all objects from remote
git fetch -p origin

# Or fetch all refs
git fetch --all

This works when the corruption is local and the remote has complete data. After fetching, run git fsck --full again to verify.

3Restore objects from a backup or alternate repository

If you have another clone of the repository or a backup, you can copy missing objects:

bash
# Clone a fresh copy to /tmp
git clone <remote-url> /tmp/fresh-repo

# Add it as an alternate object store
echo "/tmp/fresh-repo/.git/objects/" > .git/objects/info/alternates

# Repack to copy missing objects
git repack -a -d

# Remove the alternate
rm .git/objects/info/alternates

Alternatively, directly copy missing objects from the fresh clone:

bash
rsync -av /tmp/fresh-repo/.git/objects/ .git/objects/
4Fix corrupt branch references

If specific branches are corrupt, you may need to reset their references:

bash
# Find the last known good commit
git log --all --oneline | head -20

# Update the branch reference to a good commit
git update-ref refs/heads/main <good-commit-hash>

# Ensure HEAD points to the correct branch
git symbolic-ref HEAD refs/heads/main

To delete corrupt empty refs:

bash
find .git/refs -size 0 -delete -print
5Clone fresh and preserve work-in-progress changes

If the repository is severely corrupted and you have uncommitted work:

bash
# Save your working tree changes
cp -r your-broken-repo your-broken-repo-backup

# Clone fresh copy
git clone <remote-url> your-repo-fixed

# Copy your working files (NOT .git) from backup
cp -r your-broken-repo-backup/* your-repo-fixed/

# Review and commit changes
cd your-repo-fixed
git status
git add .
git commit -m "Restore work after corruption"

This gives you a clean repository with your latest changes preserved.

6Use git-repair for automated recovery

On Linux systems, git-repair can automatically fix many corruption issues:

bash
# Install git-repair
sudo apt install git-repair  # Debian/Ubuntu

# Run repair from repository root
cd /path/to/repo
git-repair

# Clean up broken refs
find .git/refs -size 0 -delete -print

# Verify
git fsck --full

git-repair will attempt to recover from backups and rebuild corrupt structures automatically.

Advanced notes

Repository corruption prevention: Never store Git repositories in cloud-synced folders (OneDrive, Dropbox, iCloud) as file locking and sync conflicts can corrupt objects. Use dedicated Git hosting instead. On Windows, enable long path support with git config --system core.longpaths true to prevent path-related corruption.

If the .git/objects directory is completely lost or unrecoverable, the repository data is gone. In this case, delete the .git folder, run git init, and start fresh, optionally pulling from remote if available.

For repositories with Git LFS, ensure LFS objects are properly synced before force-pushing. Use git lfs fetch --all before operations that rewrite history.

When fsck reports "dangling" objects, these are usually harmless - they're unreachable objects from rebases, amended commits, or deleted branches. You can remove them with git gc --prune=now after confirming no data is needed.

For CI/CD systems encountering this error, check that shallow clones (--depth) aren't causing issues. Some operations require full history. Use git fetch --unshallow to convert shallow clones to full clones.

Frequently asked questions

What does "fatal: bad object in rev-list input" mean?
The git rev-list command is used internally by Git to list commit objects in reverse chronological order. When it encounters a "bad object" or "invalid object" error, it means Git is trying to access an object (commit, tree, or blob) that is either missing from the object database, corrupted, or has an invalid SHA-1 hash. This error commonly appears during operations like git push, git fetch, git clone, or git log when Git needs to traverse the commit history.
How do I fix "fatal: bad object in rev-list input"?
This error occurs when git rev-list encounters a missing, corrupted, or invalid object (commit, blob, or tree) in the repository. It typically indicates repository corruption or incomplete data transfer.
What causes "fatal: bad object in rev-list input"?
Incomplete git clone, fetch, or pull operation that was interrupted Force push to remote when local copy lacks objects the remote references Repository stored in cloud-synced folder (OneDrive, iCloud, Dropbox) causing file conflicts
Is the "fatal: bad object in rev-list input" 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