How to fix error: inflate: data stream error (incorrect data check) in Git

GitINTERMEDIATEHIGH

This error occurs when Git cannot decompress repository object data due to corruption. The zlib checksum failed, indicating damaged objects from disk failure, network issues, or memory problems.

What this error means

When Git stores objects (commits, trees, blobs), it compresses them using zlib compression. The "inflate: data stream error (incorrect data check)" message means Git attempted to decompress an object but the adler-32 checksum at the end of the zlib data did not match the inflated data. This is a serious error indicating data corruption in your repository's object database. The corruption can affect loose objects (individual files in .git/objects) or packed objects (compressed collections in .git/objects/pack). The problematic bytes could be anywhere in the object data - it's not just a header issue but actual content corruption. Common scenarios that lead to this error include: - Hard disk failures or bad sectors corrupting stored data - Network interruptions during clone, fetch, or push operations - Memory (RAM) faults causing bit flips during data processing - Buggy network drivers corrupting TCP packets when segmentation offload is enabled - Incomplete or interrupted Git operations (force shutdown during write) - File system corruption or unexpected system crashes

How to fix "error: inflate: data stream error (incorrect data check)"

1Back up your repository and identify corrupt objects

Before attempting any fixes, back up your current repository state. Then use git fsck to identify all corrupt objects.

Create a backup:

bash

# Copy the entire repository including .git directory
cp -r /path/to/repo /path/to/repo-backup

# Or just the .git folder
cp -r .git .git-backup

Run a full filesystem check:

bash

git fsck --full

This will output errors like:

bash

error: inflate: data stream error (incorrect data check)
error: unable to unpack 27c221b1620b8414de002b00aa990fd8e0d768a7 header
fatal: loose object 27c221b1620b8414de002b00aa990fd8e0d768a7 is corrupt

Note the object hash (the long hexadecimal string) - you'll need it for recovery.

2Remove corrupt loose objects

If the corruption is in loose objects (individual files in .git/objects), you can remove them and refetch from the remote.

Locate the corrupt object file:

bash

# Object hash 27c221b1620b8414de002b00aa990fd8e0d768a7 is stored at:
# .git/objects/27/c221b1620b8414de002b00aa990fd8e0d768a7
#              ^^-- first two characters form the directory name

Remove the corrupt object:

bash

rm .git/objects/27/c221b1620b8414de002b00aa990fd8e0d768a7

Run fsck again to find any additional corrupt objects:

bash

git fsck --full

Repeat this process until no more corrupt loose objects are reported.

3Refetch objects from the remote repository

After removing corrupt objects, fetch fresh copies from the remote.

Standard fetch:

bash

git fetch origin

If that doesn't work, use refetch to get all objects:

bash

git fetch --refetch

This fetches all objects as a fresh clone would, instead of only fetching objects not present locally.

Clean up unreachable objects:

bash

git reflog expire --expire-unreachable=now --all
git gc --prune=now

Verify the repository is healthy:

bash

git fsck --full

4Handle corrupt pack files

If corruption is in a pack file (.git/objects/pack/), you need to unpack it, remove the corrupt object, and repack.

Identify the corrupt pack:

The error message will show something like:

bash

fatal: packed object 32f225897e9388... (stored in .git/objects/pack/pack-b4fd0c9ada76....pack) is corrupt

Move the pack file out and unpack:

bash

# Move the corrupt pack files aside
mkdir /tmp/corrupt-pack
mv .git/objects/pack/pack-b4fd0c9ada76*.pack /tmp/corrupt-pack/
mv .git/objects/pack/pack-b4fd0c9ada76*.idx /tmp/corrupt-pack/

# Try to unpack recoverable objects
cd /tmp/corrupt-pack
git unpack-objects -r < pack-b4fd0c9ada76*.pack

The -r flag tells Git to recover what it can, skipping corrupt objects.

Refetch missing objects:

bash

cd /path/to/repo
git fetch --refetch origin

5Clone a fresh copy and migrate your work

If the corruption is extensive, the cleanest solution is to clone fresh and migrate uncommitted work.

Clone a fresh copy:

bash

git clone https://github.com/user/repo.git repo-fresh

If you have uncommitted changes, copy them over:

bash

# From the corrupt repo, copy changed files (not .git)
rsync -av --exclude='.git' /path/to/corrupt-repo/ /path/to/repo-fresh/

Check status and commit:

bash

cd repo-fresh
git status
git add .
git commit -m "Recovered uncommitted changes"

For unpushed commits, you may be able to create patches:

bash

# In the corrupt repo, if git log works
git format-patch origin/main..HEAD

# Apply patches in fresh clone
git am *.patch

6Try a shallow clone as a workaround

If the corruption affects older history, a shallow clone can bypass it.

Clone with limited history:

bash

git clone --depth=1 https://github.com/user/repo.git

Gradually deepen if needed:

bash

git fetch --deepen=100

Or unshallow completely once you confirm it works:

bash

git fetch --unshallow

This is particularly useful when you only need recent history and the corruption is in older commits.

7Recover objects from another clone or backup

If you have another clone of the repository or a backup, you can copy missing objects from there.

From another local clone:

bash

# Copy specific object
cp /path/to/other-clone/.git/objects/27/c221b162... .git/objects/27/

# Or copy entire objects directory
rsync -av /path/to/other-clone/.git/objects/ .git/objects/

From a teammate's clone:

bash

# Have them create a bundle
cd /their/clone
git bundle create repo.bundle --all

# Transfer the bundle to your machine and extract
git bundle unbundle repo.bundle

Verify after recovery:

bash

git fsck --full
git gc --prune=now

8Check for hardware issues

If corruption happens repeatedly, investigate hardware problems.

Test your RAM:

bash

# On Linux, install and run memtest86+
sudo apt install memtest86+
# Reboot and select memtest from GRUB menu

Check disk health:

bash

# Check SMART status
sudo smartctl -a /dev/sda

# Check filesystem
sudo fsck -n /dev/sda1

Check network driver issues:

If you see corruption during network operations (clone, fetch), try disabling TCP offloading:

bash

# Check current settings
ethtool -k eth0 | grep -E "(tcp|checksum)"

# Disable offloading (temporary, for testing)
sudo ethtool -K eth0 tso off gso off gro off
sudo ethtool -K eth0 rx off tx off

For persistent issues:
- Replace failing RAM modules
- Replace failing hard drives
- Use wired connections instead of WiFi for large transfers
- Update network drivers

Advanced notes

### Understanding Git Object Compression

Git uses zlib compression for all objects. When you see "incorrect data check", it means the adler-32 checksum at the end of the compressed data doesn't match what was calculated from the inflated content. This checksum is designed to detect exactly this kind of corruption.

### Single-Byte Corruption Recovery

In rare cases, corruption may be a single bit flip (possibly from a cosmic ray or memory fault). The Git documentation describes a technique for recovering from single-byte corruption:

1. Extract the raw compressed object data
2. Write a program to flip each byte systematically
3. Try inflating after each change
4. When inflation succeeds, verify the SHA-1 matches

This is documented in Git's official howto: "How to recover an object from scratch"

### Pack File Structure

Pack files contain multiple objects with delta compression. When corruption hits a base object, all delta objects depending on it become unrecoverable. That's why pack file corruption can be more severe than loose object corruption.

To examine pack file structure:

bash

# List objects in a pack
git verify-pack -v .git/objects/pack/pack-*.idx

# Show pack file index
git show-index < .git/objects/pack/pack-*.idx

### Prevention Best Practices

1. Enable transfer.fsckObjects to verify objects during transfer:

bash

git config --global transfer.fsckObjects true
   git config --global fetch.fsckObjects true
   git config --global receive.fsckObjects true

2. Run periodic integrity checks:

bash

git fsck --full

3. Use ECC RAM if repository integrity is critical

4. Maintain backups - use services like GitHub, GitLab, or local bare repository backups

5. Use reliable storage - SSDs with power-loss protection or enterprise drives

### When to Contact Hosting Provider

If you see this error when cloning from GitHub, GitLab, or similar services, and other users can clone successfully, the issue is likely local. However, if multiple users see corruption, contact the hosting provider as the remote repository may be damaged.

How to fix error: inflate: data stream error (incorrect data check) in Git

What this error means

Typical symptoms

Common causes

How to fix "error: inflate: data stream error (incorrect data check)"

Advanced notes

Related errors

Official resources & further reading