diff options
author | Taylor Blau <me@ttaylorr.com> | 2022-01-25 17:41:20 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2022-01-27 12:07:53 -0800 |
commit | f8b60cf99b0ab10d915c7bfd4802a1af45d0d439 (patch) | |
tree | 7e307480caf3d5c9ff026ae4df2b795eca65f869 /contrib/mw-to-git/Git | |
parent | midx: read `RIDX` chunk when present (diff) | |
download | tgif-f8b60cf99b0ab10d915c7bfd4802a1af45d0d439.tar.xz |
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>
Diffstat (limited to 'contrib/mw-to-git/Git')
0 files changed, 0 insertions, 0 deletions