Hi Abhradeep,
On Wed, 10 Aug 2022, Johannes Schindelin wrote:
> On Tue, 9 Aug 2022, Abhradeep Chakraborty wrote:
>
> > I noticed in the 'setup partial bitmaps' test case that if we comment
> > out the line `git repack &&` , it runs successfully.
> >
> > test_expect_success 'setup partial bitmaps' '
> > test_commit packed &&
> > # git repack &&
> > test_commit loose &&
> > git multi-pack-index write --bitmap 2>err &&
> > ...
> > '
>
> That's interesting. Are the `.bitmap` and `.midx` files updated as part of
> that `repack`?
I instrumented this, and saw that the `multi-pack-index` and
`multi-pack-index*.bitmap` files were unchanged by the `git repack`
invocation.
Re-generating the MIDX bitmap forcefully after the repack seems to fix
things over here:
-- snip --
diff --git a/t/lib-bitmap.sh b/t/lib-bitmap.sh
index a95537e759b..564124bda27 100644
--- a/t/lib-bitmap.sh
+++ b/t/lib-bitmap.sh
@@ -438,7 +438,10 @@ midx_bitmap_partial_tests () {
test_expect_success 'setup partial bitmaps' '
test_commit packed &&
+ls -l .git/objects/pack/ &&
git repack &&
+git multi-pack-index write --bitmap &&
+ls -l .git/objects/pack/ &&
test_commit loose &&
git multi-pack-index write --bitmap 2>err &&
test_path_is_file $midx &&
-- snap --
This suggests to me that the `multi-pack-index write --bitmap 2>err` call
in this hunk might reuse a stale MIDX bitmap, and that _that_ might be
the root cause of this breakage.
What do you think?
Ciao,
Dscho
