Running git-next, writing bitmap indexes fails if a keep file is present from an earlier pack.

With git at b139ac2, the following commands demonstrate the problem:

git init test
cd test
touch a
git add a
git commit -m "a"

git repack -ad  # generate a pack file
for f in .git/objects/pack/*.pack; touch ${f/%pack/keep} # mark it as to keep

touch b
git add b
git commit -m "b"
git repack -adb

This fails at the bitmap writing stage with something like:

Counting objects: 2, done.
Delta compression using up to 24 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), done.
fatal: Failed to write bitmap index. Packfile doesn't have full closure (object 7388a015938147155b600eaacc59af6e78c75e5a is missing)

In our case we have .keep files lying around from ages ago (possibly due to kill -9s run on the server). It also means that running repack -a with bitmap writing enabled on a repo becomes problematic if a fetch is run concurrently.

Even if we practice good .keep hygiene, this seems like a bug in git that should be fixed.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to