How to fix warning: bitmap file is corrupt in Git

Before regenerating the bitmap, run a full repository check to ensure there are no deeper issues:

# Run a full file system check
git fsck --full

# Check for any other corruption
git fsck --strict

If git fsck reports any errors beyond the bitmap warning, address those first. The bitmap warning alone is not a sign of repository corruption - it's just an optimization file that needs regeneration.

If fsck shows all objects are valid, proceed to regenerate the bitmap.

The bitmap file is located in your repository's pack directory. You can safely remove it:

Locate and remove the bitmap file:

# Find bitmap files in the repository
ls -la .git/objects/pack/*.bitmap

# Remove the corrupt bitmap file(s)
rm -f .git/objects/pack/*.bitmap

On Windows (PowerShell):

Get-ChildItem .git\objects\pack\*.bitmap
Remove-Item .git\objects\pack\*.bitmap -Force

Removing the bitmap file is safe - it only affects performance, not data integrity. Git will simply skip using bitmaps until a new one is generated.

The recommended way to regenerate the bitmap is using git repack with the bitmap writing option:

# Repack all objects and generate a new bitmap
git repack -a -d -b

Flags explained:
- -a: Pack all objects into a single pack (required for bitmaps)
- -d: Delete redundant packs after repacking
- -b: Write a reachability bitmap index

For large repositories, add progress output:

git repack -a -d -b --progress

This command will create a new .bitmap file alongside your pack file in .git/objects/pack/.

You can also use git gc (garbage collection) to regenerate the bitmap:

# Run garbage collection which includes repacking with bitmaps
git gc

# Or force an aggressive cleanup
git gc --aggressive

To ensure bitmaps are written during gc:

# Check current configuration
git config --get repack.writeBitmaps

# Enable bitmap writing if not set
git config repack.writeBitmaps true

# Then run gc
git gc

Note: git gc --aggressive takes significantly longer but produces better compression. For most cases, regular git gc is sufficient.

After repacking, verify that a new bitmap file was created:

# Check for new bitmap files
ls -la .git/objects/pack/*.bitmap

# Run a git operation to confirm no warning appears
git count-objects -v

# Or run fsck to verify everything is clean
git fsck

If no bitmap file was created, check for conditions that prevent bitmap generation:
- Multiple pack files exist (bitmap requires a single pack)
- The pack.packSizeLimit configuration is set (forces multiple packs)
- The repository uses alternates (bitmaps not supported with alternates)

Check for issues:

# Count pack files
ls -l .git/objects/pack/*.pack | wc -l

# Check packSizeLimit
git config --get pack.packSizeLimit

# Check for alternates
cat .git/objects/info/alternates 2>/dev/null

If your repository has multiple pack files, traditional single-pack bitmaps won't work. Instead, use the multi-pack index (MIDX) with bitmaps:

# Write a multi-pack index with bitmap
git multi-pack-index write --bitmap

# Verify the MIDX was created
ls -la .git/objects/pack/multi-pack-index*

Requirements for MIDX bitmaps:
- Git version 2.32 or later
- Multiple pack files in the repository

Or consolidate into a single pack:

# Remove pack size limit if set
git config --unset pack.packSizeLimit

# Repack into single pack with bitmap
git repack -a -d -b

Choose the MIDX approach if you intentionally maintain multiple packs (e.g., for incremental backups), otherwise consolidate into a single pack.