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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html