How to fix error: wrong type for object in Git

GitINTERMEDIATEMEDIUM

The 'wrong type for object' error occurs when Git encounters an object with a mismatched type in its object database. This typically indicates repository corruption where a blob, tree, commit, or tag object doesn't match its expected type. Recovery involves fetching missing objects from remote or restoring from backups.

What this error means

The "error: wrong type for object" message means Git found an object in its database that has an unexpected type. Git stores all repository data as four types of objects: blobs (file contents), trees (directory structures), commits (snapshots with metadata), and tags (named references). Each object has its type embedded in its header, and Git verifies this type matches what's expected during various operations. When Git tries to read an object expecting one type (for example, a tree to list directory contents) but finds a different type (like a blob or corrupted data), it reports this error. This mismatch prevents Git from correctly parsing the object and understanding the repository structure. This error commonly occurs during operations that traverse the commit graph, such as `git fsck`, `git log`, `git checkout`, or when applying patches. The corruption can affect a single object or indicate broader repository damage. The good news is that Git's content-addressable storage means the correct object may exist elsewhere (on a remote or in a backup), making recovery possible in most cases.

How to fix "error: wrong type for object"

1Run git fsck to identify corrupted objects

First, diagnose the extent of corruption by running a full filesystem check:

bash

# Run full integrity check
git fsck --full

# For more detailed output including unreachable objects
git fsck --full --verbose

# Check for specific object type mismatches
git fsck --full 2>&1 | grep "wrong type"

This will list all problematic objects with their SHA-1 hashes. Note these hashes as you'll need them for targeted repairs. The output might look like:

bash

error: wrong type for object abc123def456...
error: unable to read tree 789xyz...

2Check the actual object type

Use git cat-file to examine what type the corrupted object actually is:

bash

# Check the type of a specific object
git cat-file -t <object-hash>

# Get the size of the object
git cat-file -s <object-hash>

# Try to display object contents
git cat-file -p <object-hash>

This helps you understand what Git found versus what it expected. For example, if Git expected a tree but found a blob, the output of -t would show "blob" instead of "tree".

3Fetch missing or correct objects from remote

If you have a remote repository, fetching often resolves the issue by downloading correct object versions:

bash

# Fetch all objects from origin
git fetch origin

# More thorough fetch that re-downloads pack files
git fetch --refetch

# Fetch with verbose output to see what's being downloaded
git fetch -v origin

# If standard fetch doesn't help, try fetching with prune
git fetch --prune origin

After fetching, run git fsck --full again to check if the corruption is resolved.

4Remove corrupted objects and re-fetch

If fetching alone doesn't work, manually remove the corrupted objects:

bash

# Objects are stored in .git/objects/XX/YYYYYYYY...
# For object abc123def456..., the path would be:
# .git/objects/ab/c123def456...

# Remove a specific corrupted object
rm .git/objects/ab/c123def456...

# Remove all empty object files (common corruption pattern)
find .git/objects/ -type f -empty -delete

# Now fetch to get correct versions
git fetch origin

# Run fsck again to verify
git fsck --full

Removing the corrupted object forces Git to either report it as missing (instead of wrong type) or fetch it fresh from the remote.

5Unpack objects from a fresh clone

Clone a fresh copy and extract its objects to repair your repository:

bash

# Clone to a temporary location
git clone --bare <your-remote-url> /tmp/fresh-repo.git

# Unpack objects from the fresh clone's pack files
cd /tmp/fresh-repo.git
git unpack-objects < objects/pack/*.pack

# Copy the unpacked objects to your corrupted repository
cp -r objects/* /path/to/corrupted-repo/.git/objects/

# Return to your repository and verify
cd /path/to/corrupted-repo
git fsck --full

This approach is useful when packed objects in your repository are corrupted but the remote has correct data.

6Copy specific objects from another clone

If you have another working clone of the same repository:

bash

# In the working repository, find and copy the needed object
# For object abc123def456...:
cd /path/to/working-repo

# Verify the object exists and is correct
git cat-file -t abc123def456
git cat-file -p abc123def456

# Copy it to the corrupted repository
cp .git/objects/ab/c123def456... /path/to/corrupted/.git/objects/ab/

# Alternatively, copy entire objects directory
rsync -av .git/objects/ /path/to/corrupted/.git/objects/

This is particularly useful when you have a local backup or another developer has a healthy clone.

7Rebuild the index and reset HEAD

If the corruption affects your working tree or index:

bash

# Remove the index and rebuild it
rm .git/index
git reset

# If HEAD is also affected, reset to a known good commit
# Find recent commits from the reflog
cat .git/logs/HEAD

# Reset to a valid commit
git reset --hard <known-good-commit-hash>

# Alternatively, reset to remote branch
git reset --hard origin/main

Rebuilding the index recreates the staging area from scratch based on HEAD, which can resolve type mismatches in the index.

8Use git-repair for automated recovery

The git-repair tool automates many recovery steps:

bash

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

# macOS:
brew install git-repair

# Run automated repair
git-repair

# For more aggressive repair (may lose some data)
git-repair --force

git-repair systematically checks for corruption and attempts multiple recovery strategies. It's especially helpful for complex corruption scenarios involving multiple objects.

9Fresh clone as last resort

If corruption is extensive, clone fresh and migrate your local changes:

bash

# Backup your current working directory changes
cp -r . ../repo-backup

# Clone fresh repository
git clone <your-remote-url> ../repo-fresh

# Copy your working files (excluding .git)
rsync -av --exclude='.git' . ../repo-fresh/

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

# Check status and commit any uncommitted changes
git status
git diff

This ensures a clean repository state while preserving your local file modifications.

Advanced notes

### Understanding Git Object Types

Git uses four object types stored in .git/objects/:

| Type | Purpose | Typical Size |
|------|---------|--------------|
| blob | Stores file contents (no filename or metadata) | Varies with file size |
| tree | Directory listing: maps names to blobs/trees with modes | Small (list of entries) |
| commit | Snapshot: points to tree, parents, author, message | Small (metadata) |
| tag | Named reference to another object with metadata | Small (reference + message) |

Each object starts with a header: <type> <size>\0 followed by the content. The SHA-1 hash is computed over this entire structure. When Git says "wrong type," it means the header declares one type but the context expects another.

### Object Reference Chain

bash

HEAD -> refs/heads/main -> commit -> tree -> blob
                                  -> tree -> blob
                                          -> blob

A "wrong type" error breaks this chain. For example:
- If a tree entry says file.txt points to hash X as a blob, but X is actually a tree
- If a commit says its tree is hash Y, but Y is actually a blob

### Diagnosing with Low-Level Commands

bash

# Show raw object header
git cat-file --batch-check <<< "<hash>"

# Inspect packed objects
git verify-pack -v .git/objects/pack/*.idx | grep <partial-hash>

# Show object as stored (with header)
git cat-file blob <hash> | xxd | head

# List all objects in the repository
git rev-list --all --objects

### Cloud Sync Prevention

Never sync .git folders with cloud services. They don't understand Git's atomic operations:

bash

# Dropbox: Add to ignore
echo ".git" >> .dropboxignore

# OneDrive: Use .nosync extension
mv .git .git.nosync && ln -s .git.nosync .git

# Better: Use Git hosting (GitHub, GitLab) instead of file sync

### Preventing Future Corruption

bash

# Enable automatic integrity checks
git config --global transfer.fsckObjects true
git config --global fetch.fsckObjects true
git config --global receive.fsckObjects true

# Set up regular gc with integrity check
git config --global gc.auto 256

# Check repository health periodically
git fsck --full --no-dangling

### Recovery from Packed Objects

Objects are often stored in pack files for efficiency. If loose objects are corrupted but packs are intact:

bash

# List contents of pack files
git verify-pack -v .git/objects/pack/*.idx

# Unpack all packed objects to loose format
git unpack-objects < .git/objects/pack/*.pack

# This creates loose objects that may replace corrupted ones
# Then you can delete corrupted pack files and repack
git repack -a -d

### Memory and Hardware Considerations

If you see repeated corruption, check hardware:

bash

# Linux: Test memory with memtest86+
# Check disk health
smartctl -a /dev/sda

# Use ECC RAM for critical development machines
# Consider using ZFS or btrfs for checksumming

Repeated "wrong type" errors without obvious cause may indicate failing hardware, especially RAM or storage.

How to fix error: wrong type for object in Git

What this error means

Typical symptoms

Common causes

How to fix "error: wrong type for object"

Advanced notes

Related errors

Official resources & further reading