Fix Git error: object file is empty in corrupted repos

Overview

The Git error “error: object file … is empty” indicates a corrupted loose object in .git/objects, usually from interrupted network operations, disk issues, or abrupt termination. This guide shows safe, practical recovery steps for developer workstations, CI agents, and bare server repos.

Quickstart (safe default)

• Make a backup copy of your repository folder (including .git).
• Remove empty loose objects, then verify and rebuild packs.
• Fetch missing objects from the remote, then re-verify.

Minimal commands:

# inside your repo
cp -a . ../repo-backup-$(date +%s)

# remove empty loose objects
find .git/objects -type f -empty -print -delete

# verify integrity
git fsck --full

# refetch and repack to restore missing objects
git fetch --all --prune
git repack -Ad
git prune --expire=now
git fsck --full

If fsck still reports missing/corrupt objects and you have a good remote, reclone.

Minimal working example (script)

This script removes empty objects, verifies, and attempts recovery by fetching and repacking. Works for non-bare repos and bare repos (set REPO path).

#!/usr/bin/env bash
set -euo pipefail
REPO="${1:-.}"
if [ ! -d "$REPO/.git" ] && [ ! -f "$REPO/HEAD" ]; then
  echo "Error: $REPO is not a Git repo (non-bare or bare)." >&2; exit 1
fi

# Normalize GIT_DIR for bare or non-bare
if [ -d "$REPO/.git" ]; then
  GIT_DIR="$REPO/.git"; WORKTREE="$REPO"
else
  GIT_DIR="$REPO"; WORKTREE=""
fi

echo "Backing up to ${REPO%/}-backup-$(date +%s)"; cp -a "$REPO" "${REPO%/}-backup-$(date +%s)"

# Remove empty loose objects
find "$GIT_DIR/objects" -type f -empty -print -delete || true

# Verify
GIT_DIR="$GIT_DIR" git fsck --full || true

# Attempt recovery via fetch/repack
if [ -n "$WORKTREE" ]; then
  git -C "$WORKTREE" fetch --all --prune || true
else
  GIT_DIR="$GIT_DIR" git fetch --all --prune || true
fi
GIT_DIR="$GIT_DIR" git repack -Ad
GIT_DIR="$GIT_DIR" git prune --expire=now
GIT_DIR="$GIT_DIR" git fsck --full

Usage:

./git-repair-empty-objects.sh /path/to/repo

Step-by-step resolution

1. Confirm the problem

• Run: git fsck --full
• Typical outputs: “error: object file .git/objects/ab/cdef... is empty” or “missing blob …”.

1. Back up before modifying

• Copy the entire repo directory, including .git. This lets you recover unpushed work if needed.

1. Remove empty loose objects

• Command: find .git/objects -type f -empty -delete
• Why: Git may have created zero-byte loose objects from an interrupted write.

1. Verify and identify scope

• Run: git fsck --full
• If only loose objects were empty, fsck may now pass. If you see missing objects, go to step 5.

1. Rehydrate from remote

• Run: git fetch --all --prune
• If your branch had missing commits, reset to the remote tip: git reset --hard origin/<branch>
• For bare repos: use GIT_DIR=/path/to/repo git fetch --all --prune

1. Repack and prune

• Run: git repack -Ad followed by git prune --expire=now
• This consolidates objects into packs and cleans unreachable ones.

1. Final integrity check

• Run: git fsck --full
• If errors persist, see “Handle pack corruption” or “When to reclone”.

Handle pack corruption

If fsck mentions packs (pack-*.pack / .idx):

• Remove the bad pack files and refetch:

# identify suspicious packs (optional)
ls -lh .git/objects/pack

# move packs aside and refetch
mkdir -p .git/objects/pack.bad
mv .git/objects/pack/pack-*.pack .git/objects/pack/pack-*.idx .git/objects/pack.bad/ || true
git fetch --all --prune
git repack -Ad
git fsck --full

• For bare repos, prefix with GIT_DIR=/path/to/repo.

When to reclone

Reclone if any of these apply:

• fsck still reports missing or corrupt objects after cleanup, fetch, and repack.
• There is no reliable remote or backup to restore missing objects.
• Disk or filesystem problems recur after repair.

Commands:

cd ..
mv repo repo-broken-$(date +%s)
git clone --mirror <url> repo  # for server/bare mirrors
# or for working repos
git clone <url> repo

To restore local work after reclone:

• From backup: cherry-pick commits reachable only in the old repo.
• Or use git format-patch in the backup and apply in the new clone.

Common scenarios and actions

Pitfalls

• Losing unpushed work: Hard resets and pruning can drop commits not on any remote. Back up first and check git reflog.
• Running prune too early: If objects are only referenced by reflogs, pruning with aggressive expiry can delete them. Use prune cautiously.
• Bare vs non-bare commands: In bare repos, many commands need GIT_DIR set or use git -C with the repo path.
• Filesystem errors: If the underlying disk is corrupt, Git repair won’t stick. Run OS-level fsck/chkdsk first.

Performance notes

• git repack -Ad can be CPU and I/O intensive on large repos. Run during maintenance windows on servers.
• To reduce impact on busy servers, consider: git repack -Ad --write-bitmap-index and schedule with low I/O priority.
• Avoid repeated repacks in CI. Prefer clean clones or shared object caches that are validated.
• Using git fetch --depth=N on CI reduces transfer size; if corruption is frequent, don’t reuse workspaces.

Verification checklist

• git fsck --full returns no errors.
• git log and git status behave normally on all active branches.
• Push/pull works without warnings.

Preventing recurrence

• Ensure stable storage and adequate free space on agents and servers.
• Don’t kill Git during network/object writes; let fetch/clone complete.
• Schedule git gc on long-lived repos (e.g., git gc --aggressive during maintenance).
• Keep mirrors fresh with git fetch --all --prune and periodic repacks.

FAQ

Q: What causes “object file … is empty”?
A: Interrupted writes (power loss, kill -9), disk full, filesystem issues, or aborted network transfers.

Q: Is deleting empty objects safe?
A: Yes. Zero-byte objects are invalid; Git will refetch or rebuild needed ones.

Q: I can’t fetch a missing object—what now?
A: The only copy may be lost. Check backups, other clones, or the server’s reflogs. If unavailable, you may need to reconstruct work manually.

Q: Should I run git gc --prune=now?
A: Use repack/prune first. gc wraps these and may be heavier. On servers, schedule it to avoid contention.