]> git.ipfire.org Git - thirdparty/git.git/commit
pack-bitmap.c: gracefully fallback after opening pack/MIDX
authorTaylor Blau <me@ttaylorr.com>
Tue, 25 Jan 2022 22:41:20 +0000 (17:41 -0500)
committerJunio C Hamano <gitster@pobox.com>
Thu, 27 Jan 2022 20:07:53 +0000 (12:07 -0800)
commitf8b60cf99b0ab10d915c7bfd4802a1af45d0d439
tree7e307480caf3d5c9ff026ae4df2b795eca65f869
parent7f514b7a5e775cd0b7a9543b02bf9dd38b164d02
pack-bitmap.c: gracefully fallback after opening pack/MIDX

When opening a MIDX/pack-bitmap, we call open_midx_bitmap_1() or
open_pack_bitmap_1() respectively in a loop over the set of MIDXs/packs.
By design, these functions are supposed to be called over every pack and
MIDX, since only one of them should have a valid bitmap.

Ordinarily we return '0' from these two functions in order to indicate
that we successfully loaded a bitmap To signal that we couldn't load a
bitmap corresponding to the MIDX/pack (either because one doesn't exist,
or because there was an error with loading it), we can return '-1'. In
either case, the callers each enumerate all MIDXs/packs to ensure that
at most one bitmap per-kind is present.

But when we fail to load a bitmap that does exist (for example, loading
a MIDX bitmap without finding a corresponding reverse index), we'll
return -1 but leave the 'midx' field non-NULL. So when we fallback to
loading a pack bitmap, we'll complain that the bitmap we're trying to
populate already is "opened", even though it isn't.

Rectify this by setting the '->pack' and '->midx' field back to NULL as
appropriate. Two tests are added: one to ensure that the MIDX-to-pack
bitmap fallback works, and another to ensure we still complain when
there are multiple pack bitmaps in a repository.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-bitmap.c
t/t5310-pack-bitmaps.sh
t/t5326-multi-pack-bitmaps.sh