How to fix error: bad index file sha1 signature fatal: index file corrupt in Git

First, confirm that the index is actually corrupt and understand the scope of the issue:

# Check the error message
git status

# Examine the index file
ls -la .git/index

# Check if the file is empty or suspiciously small
# A normal index is typically at least a few KB
file .git/index

If you see output like:
- error: bad index file sha1 signature
- fatal: index file corrupt
- File size is 0 bytes or very small

Then the index is indeed corrupt and needs to be regenerated.

Before removing the index, try to preserve any uncommitted work. The index stores your staged changes, so if you had changes staged, they may be lost. However, your actual working directory files are separate from the index.

# Your working directory files should still be intact
# List modified files based on filesystem state
find . -newer .git/index -type f 2>/dev/null | head -20

# If you have important uncommitted changes, copy them elsewhere
cp -r . ../backup-$(date +%Y%m%d)

Important: Your committed history is safe. Only staged but uncommitted changes might be affected. If you were in the middle of staging specific hunks or had a carefully curated index, that precise staging state will be lost.

Delete the corrupted index file. This is safe because Git can regenerate it from HEAD:

# Remove the corrupt index
rm -f .git/index

# On Windows (Command Prompt):
del .git\index

# On Windows (PowerShell):
Remove-Item .git\index -Force

If you get a permission denied error, ensure no Git processes or IDE integrations are running, then try again.

Rebuild the index from the last commit. You have two options depending on whether you want to preserve working directory changes:

Option A: Reset the index only (preserves working directory changes)

# Regenerate index from HEAD, keeping working directory files
git reset

This recreates the index from your last commit but leaves your working directory files untouched. Modified files will show as "modified" in git status.

Option B: Use read-tree (alternative method)

# Read the tree from HEAD into the index
git read-tree HEAD

This does essentially the same thing as git reset but is more explicit about what it's doing.

After either command:

# Verify the index is working
git status

You should now see a normal status output showing any differences between your working directory and HEAD.

After regenerating the index, any changes you had staged will need to be re-staged:

# See what files differ from HEAD
git status

# Re-stage all changes
git add -A

# Or stage specific files
git add path/to/file.txt

# If you want to review changes before staging
git diff
git add -p  # Interactive staging

If you had specific files staged before the corruption, you'll need to stage them again. The precise staging state (e.g., partial hunks) cannot be recovered.

If the corruption happened once due to a crash, you're done. But if it keeps recurring, investigate the root cause:

# Check disk health (Linux)
sudo dmesg | grep -i error
sudo smartctl -a /dev/sda  # Replace with your disk

# Check filesystem (unmount first if possible)
sudo fsck -n /dev/sda1

# On macOS
diskutil verifyVolume /

# Check for processes accessing .git
lsof +D .git

Common recurring causes:
- Antivirus software: Add the repository folder to exclusions
- Cloud sync (Dropbox, OneDrive): Don't sync .git directories
- Failing hardware: Check SMART data, run memory tests
- NFS issues: Consider working with local storage

If the problem recurs on NFS or network storage, Git's index locking may not work correctly. Consider cloning to local storage.

After recovering from index corruption, verify the rest of your repository is healthy:

# Run Git's filesystem check
git fsck --full

# Check for any missing or corrupt objects
git fsck --connectivity-only

If git fsck reports problems like missing objects or corrupt commits, you may need more extensive recovery. In that case:

# Try to fetch missing objects from remote
git fetch --all

# If objects are still missing, you may need to re-clone
git clone <remote-url> ../repo-fresh

For most index corruption cases, git fsck should report no errors after regenerating the index.