How to fix broken link from tree abc1234 to blob def5678 in Git

GitADVANCEDHIGH

This error indicates repository corruption where a Git tree object references a blob (file) that is missing from the object database. Recovery involves restoring the missing object from another clone or regenerating it from the working directory.

What this error means

The "broken link from tree to blob" error is reported by `git fsck` when it detects corruption in your Git repository's object database. Git stores your repository data as objects: commits point to trees, trees point to other trees (subdirectories) and blobs (file contents). Each object is identified by a SHA-1 hash of its contents. When Git reports "broken link from tree abc1234 to blob def5678", it means that the tree object (representing a directory) references a blob object (representing a file's contents) that doesn't exist in the object database. The tree "knows" about a file that should be there, but the actual file data is missing. This type of corruption typically occurs due to incomplete Git operations (interrupted clone, fetch, or push), filesystem corruption (disk errors, power loss during write), aggressive garbage collection, or issues with network-attached storage. The repository is in an inconsistent state and cannot fully reconstruct the commit history until the missing objects are recovered or the corrupted references are removed.

How to fix "broken link from tree abc1234 to blob def5678"

1Identify the scope of corruption

First, run a full repository check to understand what's broken:

bash

git fsck --full --name-objects

The --name-objects flag shows how the broken objects are reachable, helping identify which files are affected:

bash

broken link from tree b5eb6ff... (HEAD~25^{tree}:src/) to blob ec5cf80...

This tells you the missing blob was in the src/ directory, 25 commits behind HEAD.

Save the output to analyze which objects are missing:

bash

git fsck --full --name-objects 2>&1 | tee fsck-report.txt

Check how many objects are affected:

bash

grep "broken link" fsck-report.txt | wc -l

2Find which file the missing blob belongs to

Use the tree hash from the error to identify the filename:

bash

# Replace TREE_HASH with the tree hash from the error message
git ls-tree TREE_HASH

This lists all files in that tree. Look for the blob hash mentioned in the error to find the filename.

If the tree is also corrupted or you have the commit hash, you can trace back:

bash

# Find commits that modified the area
git log --raw --all -- path/to/suspected/file

You can also use git to show what the blob should contain if you have any references to it:

bash

git show BLOB_HASH

If the blob exists in any packfile, this will display it.

3Recover from another clone

The most reliable fix is to copy the missing objects from a healthy clone of the same repository:

Option A: If you have access to another local clone:

bash

# In the healthy repository, locate the object
cd /path/to/healthy/repo
git cat-file -t BLOB_HASH  # Should output "blob"

# Copy the object file to the corrupted repo
# Objects are stored as: .git/objects/XX/YYYY... (first 2 chars / rest)
cp .git/objects/ec/5cf80... /path/to/corrupted/repo/.git/objects/ec/5cf80...

Option B: Fetch from a remote with the objects:

bash

# In the corrupted repository
git fetch --all

# Or fetch from a specific remote
git fetch origin --tags

Option C: Clone fresh and copy objects:

bash

# Clone a fresh copy
git clone --mirror <remote_url> temp-repo.git

# Copy all objects to the corrupted repo
cp -r temp-repo.git/objects/* /path/to/corrupted/repo/.git/objects/

After copying, verify the fix:

bash

git fsck --full

4Regenerate the blob from working directory

If the file still exists in your working directory (from a recent checkout), you can regenerate the blob:

bash

# Hash the file and write it to the object database
git hash-object -w path/to/file.txt

This outputs the blob's SHA-1 hash. If it matches the missing blob hash from the error, the corruption is fixed.

For multiple files, you can rehash everything:

bash

# Regenerate all blobs from current working directory
find . -type f -not -path './.git/*' -exec git hash-object -w {} \;

Then verify:

bash

git fsck --full

Note: This only works if the file content is exactly what Git expects. If the file has changed since the corrupted commit, this won't help for that specific historical blob.

5Use git-repair for automated recovery

The git-repair tool can automatically attempt to fix repository corruption:

bash

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

# Or on macOS with Homebrew
brew install git-repair

Run the repair:

bash

# Attempt to repair the repository
git-repair

# Or force repair (may lose some data)
git-repair --force

The tool will:
1. Try to recover objects from available pack files
2. Fetch missing objects from remotes
3. As a last resort with --force, remove broken references

Verify after repair:

bash

git fsck --full --no-dangling

Warning: --force mode may result in data loss if objects cannot be recovered. Use it only when other methods fail.

6Unpack objects from pack files

Sometimes the missing object exists in a pack file but isn't accessible. Try unpacking:

bash

# Move to a backup location first
mkdir -p .git/objects/pack-backup
mv .git/objects/pack/* .git/objects/pack-backup/

# Unpack each pack file
for pack in .git/objects/pack-backup/*.pack; do
  git unpack-objects < "$pack"
done

Then repack properly:

bash

git repack -a -d

Check if the corruption is resolved:

bash

git fsck --full

If the object was present in a pack but the index was corrupted, this can restore it.

7Remove corrupted references (last resort)

If the missing objects cannot be recovered and you need a working repository, you can remove the corrupted references:

Warning: This results in data loss. You'll lose the commits that depend on the missing objects.

bash

# Find all broken links
git fsck --full 2>&1 | grep "broken link"

# Identify which branches/refs contain the corruption
git branch --contains CORRUPTED_COMMIT_HASH

# Delete the corrupted branch or reset it
git branch -D corrupted-branch
# Or reset to before the corruption
git checkout main
git reset --hard LAST_GOOD_COMMIT

To clean up all unreachable objects:

bash

# Remove all unreachable objects
git reflog expire --expire=now --all
git gc --prune=now

As an absolute last resort, reinitialize:

bash

# Backup your working files first!
cp -r . ../backup-repo

# Reinitialize (loses all history)
rm -rf .git
git init
git add .
git commit -m "Reinitialize after repository corruption"

8Verify the repository is healthy

After applying fixes, thoroughly verify the repository:

bash

# Full integrity check
git fsck --full --strict --no-dangling

# Verify all refs are valid
git for-each-ref --format='%(refname)' | while read ref; do
  git rev-parse --verify "$ref" >/dev/null 2>&1 || echo "Invalid ref: $ref"
done

# Run garbage collection
git gc --aggressive

# Test common operations
git log --oneline -20
git status
git branch -a

If everything passes, push your repaired repository to update remotes:

bash

git push --all origin
git push --tags origin

Tip: Set up regular repository health checks in CI:

yaml

# .github/workflows/fsck.yml
name: Repository Health Check
on:
  schedule:
    - cron: '0 0 * * 0'  # Weekly
jobs:
  fsck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - run: git fsck --full

How to fix broken link from tree abc1234 to blob def5678 in Git

What this error means

Typical symptoms

Common causes

How to fix "broken link from tree abc1234 to blob def5678"

Advanced notes

Related errors

Official resources & further reading