Recover lost workUsually recoverable

Repair a corrupted Git repository

Git says 'object file is empty' or 'loose object is corrupt' — can I repair it?

If you’re seeing this error

error: object file .git/objects/ab/cdef… is empty
fatal: loose object abcdef… is corrupt

You’re in the right place — the fix is below.

Short answer

Corruption is almost always a few damaged object files after a crash, disk problem or a killed process. Run git fsck to identify them, delete the empty or unreadable ones, and re-fetch the good copies from your remote. If you have a remote, a fresh clone is often the fastest fix.

quick fix
git fsck --full

Identifies exactly which objects are damaged or missing

Does this match your situation?

  • 'error: object file .git/objects/ab/cdef... is empty'.
  • 'fatal: loose object ... is corrupt'.
  • 'error: bad signature' or 'index file corrupt'.
  • It started after a crash, power loss, full disk, or a killed Git process.

Step-by-step fix

  1. Back up the whole folder before touching anything

    Repair involves deleting files. Take a copy first so a wrong move doesn't make a recoverable situation permanent.

    step 1
    cp -r my-repo my-repo-backup
    Show the PowerShell (Windows) version
    PowerShell (Windows)
    Copy-Item my-repo my-repo-backup -Recurse

  2. Diagnose the exact damage

    fsck checks every object and names the broken ones. Note the paths and hashes it reports — those are what you'll repair.

    step 2
    git fsck --full

# 'index file corrupt' only? that one is trivially fixable:
rm -f .git/index
git reset

  3. Remove empty and corrupt loose objects

    Zero-length object files are the classic result of a crash mid-write. They can't be repaired, only deleted and re-fetched.

    step 3
    find .git/objects/ -type f -empty -delete

# then let fsck confirm what's still missing:
git fsck --full
    Show the PowerShell (Windows) version
    PowerShell (Windows)
    Get-ChildItem .git\objects -Recurse -File |
  Where-Object { $_.Length -eq 0 } |
  Remove-Item -Force
git fsck --full

  4. Re-download the missing objects from your remote

    If the repo is pushed anywhere, the good copies of those objects exist there. Fetching restores them without losing your local branches.

    step 4
    git fetch --all
git fsck --full     # should be clean now

  5. Clear a broken reflog or ref if fsck still complains

    Damaged reflog entries and refs are safe to remove — they're bookkeeping, not history. You lose undo depth, not commits.

    step 5
    rm -rf .git/logs
git reflog expire --stale-fix --all
git gc --prune=now

    Deleting .git/logs destroys your reflog. Only do this once you've recovered anything you needed from it.

  6. When repair isn't worth it, re-clone

    If the work is pushed, a fresh clone is faster and guaranteed clean. Copy across any uncommitted files from the backup afterwards.

    step 6
    cd ..
git clone git@github.com:USER/REPO.git repo-fresh
# copy uncommitted work from the backup by hand

Why this works

Git's object database is a set of immutable, content-addressed files, and every object's name is the hash of its contents. That makes corruption easy to detect — the file no longer hashes to its own name — but impossible to repair in place, since there's no redundancy in a single copy. Recovery works because Git is distributed: the identical object almost certainly exists in your remote or a colleague's clone, and because objects are content-addressed, any copy is byte-for-byte interchangeable.

If that didn’t work

  • A colleague's clone or your remote can supply any missing object - copy .git/objects entries directly if a fetch won't reach them.
  • git cat-file -t <hash> on each reported hash tells you whether the missing object is a blob, tree or commit, and therefore how much is affected.
  • If your disk caused this, run a filesystem check before trusting the repository again.

How to stop it happening again

  • Push often - a remote is a complete, verified backup of every object.
  • Keep repositories off network drives and cloud-sync folders.
  • Don't kill Git mid-operation, and keep enough free disk space for it to finish writes.

Commands used in this guide

git fsck

Scan the object database for orphaned commits and blobs the reflog no longer lists.

git gc

Compress the repository and delete unreachable objects.

git fetch

Download new commits from the remote without changing any of your files.

git clone

Copy a remote repository, its full history and its branches, onto your machine.

git reflog

The undo history for everything - the single most important recovery command.

Still stuck?

Search the full command reference and every other rescue guide — there are 76 of them, covering everything from detached HEAD to force-push disasters.

Browse all guides →

Frequently asked questions

What does 'object file is empty' mean?

A file in .git/objects has zero bytes, which happens when Git was interrupted mid-write by a crash, power loss or a full disk. The object can't be repaired, but it can be deleted and re-fetched from a remote that has an intact copy.

Can I fix a corrupt repository without losing my commits?

Usually yes. Delete the damaged objects and re-fetch from your remote — because objects are content-addressed, the copies there are identical. You only lose commits that existed solely on the corrupted machine and were never pushed.

Is it faster to just re-clone?

Often, yes. If everything important is pushed, cloning fresh takes minutes and is guaranteed clean. Repair is worth attempting when you have unpushed commits that exist nowhere else.

Related rescue guides

Always fixable

Git says another git process seems to be running — how do I fix index.lock?

Git locks the index while it works and removes the lock when it finishes. A crashed command, a killed process or an editor's background Git integration can leave the lock behind. Confirm nothing is actually running, then delete .git/index.lock.

Read the fix →Always fixable

Git says 'not a git repository (or any of the parent directories): .git' — what does that mean?

You are standing somewhere Git does not consider a repository. Run pwd and ls -a: if there is no .git folder here or in any parent, either cd into the project, or run git init to create one. If .git used to be here and has vanished, the repository is not broken so much as missing — check whether you deleted it or are in a copied folder.

Read the fix →Always fixable

Cloning or pushing dies with 'RPC failed' or 'the remote end hung up unexpectedly' — how do I get it through?

The connection dropped part-way through a large transfer. Nothing is damaged. Clone shallow to make the transfer small enough to finish (git clone --depth 1), then deepen it with git fetch --unshallow. Switching the remote to SSH avoids the HTTP layer entirely and fixes most stubborn cases.

Read the fix →Always fixable

My .git folder is enormous — how do I find the biggest files in history?

git count-objects -vH tells you the total size; combining git rev-list --objects with git cat-file --batch-check lists the largest blobs by name. Deleting the files now won't shrink anything — they have to be purged from history.

Read the fix →
← All Git Rescue guides