How to fix fatal: bad object abc1234 in Git

GitINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 252 views

Git reports 'fatal: bad object' when it cannot find or read a referenced object in the repository database. This typically occurs during git gc, status, or other operations when a commit, tree, or blob is missing or corrupted due to incomplete operations, shallow clones, or filesystem issues.

Quick fix

Fixes fatal: bad object abc1234

# Run fsck to find all bad objects
git fsck --full

# Check what refs exist
git show-ref

# Look at the specific error - if it mentions a path like
# refs/remotes/origin/HEAD, check that file:
cat .git/refs/remotes/origin/HEAD
  1. Identify the problematic reference
  2. Fix remote HEAD pointing to deleted branch
  3. Delete corrupted references manually
  4. Fetch missing objects from remote
git — error
# Run fsck to find all bad objects
git fsck --full
# Check what refs exist
git show-ref
# Look at the specific error - if it mentions a path like
# refs/remotes/origin/HEAD, check that file:
cat .git/refs/remotes/origin/HEAD
fatal: bad object abc1234

What this error means

The "fatal: bad object" error indicates Git cannot locate or read an object (commit, tree, blob, or tag) that is referenced somewhere in your repository. Every piece of data in Git is stored as an object identified by a 40-character SHA-1 hash. When Git needs to access an object but finds it missing, corrupted, or unreadable, it throws this fatal error. This error commonly appears during garbage collection (`git gc`), but can occur with any Git command that needs to traverse the object graph. The referenced object hash in the error message (e.g., `abc1234`) tells you exactly which object Git cannot find. Common scenarios that trigger this error include: - Running `git gc` when remote tracking branches point to deleted or unavailable objects - Shallow clones missing referenced parent commits - Repository corruption from interrupted operations or disk issues - Cloud sync services (Dropbox, iCloud, OneDrive) causing partial .git folder syncs - Stale references to objects that were pruned or never fetched

Typical symptoms

  • git gc fails with 'fatal: bad object refs/remotes/origin/HEAD' or similar reference path
  • git status, log, or other commands fail with 'fatal: bad object <hash>'
  • Error appears after renaming or deleting remote branches
  • Repository operations fail after cloning with --depth (shallow clone)
  • Multiple 'bad object' errors appear when running git fsck
  • CI/CD pipelines fail during git operations on cached repositories

Common causes

  1. Remote tracking reference (refs/remotes/origin/HEAD) points to a deleted or renamed branch
  2. Shallow clone is missing parent commits that are now being referenced
  3. Repository corruption from interrupted git operations (fetch, push, gc)
  4. Cloud sync services (Dropbox, iCloud, Google Drive) partially syncing .git folder
  5. Manual deletion or modification of files in .git/objects directory
  6. Force-pushed remote changes that invalidated local object references
  7. Concurrent git processes causing race conditions during garbage collection
  8. Disk space exhaustion during Git operations leaving partial objects

How to fix "fatal: bad object abc1234"

1Identify the problematic reference

First, determine which reference is causing the issue:

bash
# Run fsck to find all bad objects
git fsck --full

# Check what refs exist
git show-ref

# Look at the specific error - if it mentions a path like
# refs/remotes/origin/HEAD, check that file:
cat .git/refs/remotes/origin/HEAD

Note the object hash and reference path from the error message - this guides which fix to apply.

2Fix remote HEAD pointing to deleted branch

If the error mentions refs/remotes/origin/HEAD, the remote's default branch may have been renamed or deleted:

bash
# Auto-detect and update the remote HEAD
git remote set-head origin --auto

# If that fails, manually set it to the correct branch
git remote set-head origin main

# Prune stale remote-tracking references
git remote prune origin

# Verify the fix
git gc

This is the most common cause of "bad object" errors during git gc.

3Delete corrupted references manually

If a specific reference file is corrupted, you can remove it:

bash
# First, check what the reference contains
cat .git/refs/remotes/origin/HEAD

# If it shows an invalid hash (all zeros, truncated, or garbled):
# Delete the corrupted reference
git update-ref -d refs/remotes/origin/HEAD

# For other corrupted refs, use the same pattern:
git update-ref -d "<corrupted-ref-path>"

# Then verify and fetch fresh data
git fetch origin
git gc

You can also manually delete the file: rm .git/refs/remotes/origin/HEAD

4Fetch missing objects from remote

If objects are missing (common with shallow clones), fetch them:

bash
# Fetch all objects from all remotes
git fetch --all

# For shallow clones, unshallow to get full history
git fetch --unshallow

# Fetch with full object download
git fetch --refetch

# If specific branches are problematic:
git fetch origin main:refs/remotes/origin/main

After fetching, try your original command again.

5Recover objects from reflog

Git's reflog may contain references to the missing objects:

bash
# View reflog entries
git reflog

# Check all reflogs for the missing hash
git reflog --all | grep <partial-hash>

# If found, the object still exists - create a reference to prevent pruning
git branch recovered-<hash> <full-hash>

Objects referenced by reflog are protected from garbage collection.

6Repair pack files

If the error occurs during gc with pack file issues:

bash
# Unpack all pack files (creates loose objects)
git unpack-objects < .git/objects/pack/*.pack

# Remove old pack files
rm .git/objects/pack/*

# Repack the repository
git repack -a -d

# Run gc again
git gc

Warning: This can be slow for large repositories.

7Clone fresh and migrate changes

If corruption is extensive, clone a fresh copy:

bash
# Clone to a new directory
git clone <remote-url> repo-fresh

# If you have uncommitted changes, copy them over
# From the corrupted repo:
rsync -av --exclude='.git' ./ ../repo-fresh/

# Or on Windows:
xcopy /E /I /EXCLUDE:.git . ..\repo-fresh

# Switch to fresh clone
cd ../repo-fresh
git status

This preserves your working directory while replacing corrupted Git data.

Advanced notes

### Understanding Git Object Types

Git stores four types of objects:
- Blob: File contents (the actual data)
- Tree: Directory structure pointing to blobs and other trees
- Commit: Snapshot metadata with pointers to tree and parent commits
- Tag: Named reference to a specific object (usually a commit)

When you see "bad object <hash>", Git is looking for one of these objects but cannot find or read it.

### Shallow Clones and Bad Objects

Shallow clones (git clone --depth N) intentionally omit older objects to save space and time. This can cause "bad object" errors when:

bash
# Check if your repository is shallow
git rev-parse --is-shallow-repository

# View the shallow boundary
cat .git/shallow

Operations that need historical data (like cherry-picking old commits or running git gc) may fail. Use git fetch --unshallow to convert to a full clone.

### Preventing Bad Object Errors

Avoid cloud sync on .git folders:

bash
# Exclude .git from Dropbox/iCloud/OneDrive
# Add to your sync service's exclusion list
echo ".git" >> .dropboxignore  # Dropbox

Configure gc safety settings:

bash
# Prevent gc from running automatically during operations
git config --global gc.auto 0

# When running gc manually, be cautious with prune
git gc --prune=2.weeks.ago  # Default, keeps recent unreachable objects

### CI/CD Best Practices

In CI/CD environments with cached repositories:

bash
# Clean stale references before operations
git remote prune origin

# Fetch with cleanup
git fetch --prune --prune-tags

# For long-lived caches, run periodic maintenance
git maintenance run --auto

### Diagnosing with git fsck

Get detailed information about repository health:

bash
# Full integrity check with verbose output
git fsck --full --verbose

# Show connectivity issues
git fsck --connectivity-only

# Find unreachable objects that might help recovery
git fsck --unreachable --no-reflogs

### Recovery with git-repair

For complex corruption, use the git-repair tool:

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

# Install (macOS)
brew install git-repair

# Run automated repair
git-repair

# Force repair even with data loss risk
git-repair --force

Frequently asked questions

What does "fatal: bad object abc1234" mean?
The "fatal: bad object" error indicates Git cannot locate or read an object (commit, tree, blob, or tag) that is referenced somewhere in your repository. Every piece of data in Git is stored as an object identified by a 40-character SHA-1 hash. When Git needs to access an object but finds it missing, corrupted, or unreadable, it throws this fatal error.
How do I fix "fatal: bad object abc1234"?
Git reports 'fatal: bad object' when it cannot find or read a referenced object in the repository database. This typically occurs during git gc, status, or other operations when a commit, tree, or blob is missing or corrupted due to incomplete operations, shallow clones, or filesystem issues.
What causes "fatal: bad object abc1234"?
Remote tracking reference (refs/remotes/origin/HEAD) points to a deleted or renamed branch Shallow clone is missing parent commits that are now being referenced Repository corruption from interrupted git operations (fetch, push, gc)
Is the "fatal: bad object abc1234" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading