WIth git-next, writing bitmaps fails when keep files are present

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.