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

From: Siddharth Agarwal <[email-masked]>
Date: Wed, 22 Jan 2014 18:38:57 -0800

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.