summaryrefslogtreecommitdiff
path: root/object.c
diff options
context:
space:
mode:
authorLibravatar Taylor Blau <me@ttaylorr.com>2022-01-25 17:41:20 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2022-01-27 12:07:53 -0800
commitf8b60cf99b0ab10d915c7bfd4802a1af45d0d439 (patch)
tree7e307480caf3d5c9ff026ae4df2b795eca65f869 /object.c
parentmidx: read `RIDX` chunk when present (diff)
downloadtgif-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 'object.c')
0 files changed, 0 insertions, 0 deletions