diff options
| author | Taylor Blau <me@ttaylorr.com> | 2026-01-12 18:45:06 -0500 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2026-01-13 05:21:34 -0800 |
| commit | 38b72e581513dfbef784a1b808d282df1e0504d2 (patch) | |
| tree | 02f30f17e0aa51a02ea3bc94ab2209017041dbac /contrib/persistent-https | |
| parent | t/t5319-multi-pack-index.sh: drop early 'test_done' (diff) | |
| download | git-38b72e581513dfbef784a1b808d282df1e0504d2.tar.gz git-38b72e581513dfbef784a1b808d282df1e0504d2.zip | |
midx-write.c: assume checksum-invalid MIDXs require an update
In 6ce9d558ced (midx-write: skip rewriting MIDX with `--stdin-packs`
unless needed, 2025-12-10), the MIDX machinery learned how to optimize
out unnecessary writes with "--stdin-packs".
In order to do this, it compares the contents of the in-progress write
against a MIDX loaded directly from the object store. We load a separate
MIDX (as opposed to checking our update relative to "ctx.m") because the
MIDX code does not reuse an existing MIDX with --stdin-packs, and always
leaves "ctx.m" as NULL. See commit 0c5a62f14bc (midx-write.c: do not
read existing MIDX with `packs_to_include`, 2024-06-11) for details on
why.
If "ctx.m" is non-NULL, however, it is guaranteed to be checksum-valid,
since we only assign "ctx.m" when "midx_checksum_valid()" returns true.
Since the same guard does not exist for the MIDX we pass to
"midx_needs_update()", we may ignore on-disk corruption when determining
whether or not we can optimize out the write.
Add a similar guard within "midx_needs_update()" to prevent such an
issue.
A more robust fix would involve revising 0c5a62f14bc and teaching the
MIDX generation code how to reuse an existing MIDX even when invoked
with "--stdin-packs", such that we could avoid side-loading the MIDX
directly from the object store in order to call "midx_needs_update()".
For now, pursue the minimal fix.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/persistent-https')
0 files changed, 0 insertions, 0 deletions
