A 22 GB .git Folder, "wrong index v1 file size", and a Commit That Never Happened

Written by Claude (Fable 5.2) from the session transcript and the repo. An earlier Claude session (Opus 5.5) found the problem and ran the fix; dested answered three questions and edited. The first person below is dested's voice.

I asked an agent why a small repo's git objects were "20 megabytes". They were 22 gigabytes, and git couldn't read any of them:

fatal: your current branch appears to be broken
error: wrong index v1 file size in .git/objects/pack/pack-294fa44f….idx

#What the repo is

A gallery of my Factorio bases, rendered to zoomable map tiles by the mapshot mod. One HTML page, seven maps, and a lot of small JPGs.

"A lot" is the problem.

#What had happened, a year earlier

The evidence was all still in .git:

Reading that back: in September 2025 I ran git add on every tile and tried to commit "map files". Git wrote 22.7 GB of JPGs into a pack, the commit never completed, and the branch ref was left empty. I pushed nothing, forgot about it, and carried a broken 22 GB folder around for a year.

I don't know why the pack index came out the wrong size, and I didn't need to. Nothing in that pack was worth saving.

#The check that made deleting it safe

Deleting .git is only safe when everything in it exists somewhere else. Here that took three facts:

1. No local commits. The branch ref was empty and the remote had the only commit. git ls-remote origin showed it.
2. No unique file content. All 110,303 staged files still matched the working tree, so every byte in the pack was also on disk as a normal file.
3. Nothing else lives there. One branch, and a local config that held only the remote. On a repo with more history, also look for stashes and hooks you wrote.

If the first one had been false, this would be a different post, about git fsck and pack recovery.

#The fix is six commands

From the repo root:

rm -rf .git
git init -b main
git remote add origin https://github.com/<you>/<repo>.git
git fetch --depth 1 origin main
git reset origin/main
git branch -u origin/main

git reset without --hard moves the branch and the index and leaves the files alone. Afterwards the repo is at the remote's commit, and everything on disk that isn't in that commit shows as untracked.

.git went from 22.7 GB to 174 KB.

#Then keep it from happening again

Before the next git add, the ignore file:

# Mapshot tile data (~23 GB), kept local only
*/d-*/

# Factorio save zips
mapfiles/

What's left to track is 38 files, about 62 KB: the gallery page and, per map, the viewer's HTML, script, manifest and thumbnail. Those are the files the tiles hang off.

The cost is that the gallery only works on this machine. To put it on the web, the tiles go to a bucket and the page points there. Git was never going to hold them: GitHub rejects a push over 2 GB.

#Shallow clones don't fix this

I'd asked for a shallow checkout, thinking history was the weight. It wasn't. The remote had one commit. The 22 GB was my own staged files, and --depth 1 only trims history.

Two commands tell you which problem you have:

du -sh .git                 # how big it really is
git count-objects -vH       # loose objects vs packs

If size-pack is large and git log is short, the weight is in the current files or in something you staged and never committed. A shallow clone won't help. An ignore file will.