Re: [PATCH 3/4] repack: retain cruft packs in MIDXs after incremental repacks
- From
Jeff King <peff@peff.net>
- Date
- Sep 30, 2026, 20:45 UTC
- Message-ID
- <20260930204529.GB747209@coredump.intra.peff.net>
- In-Reply-To
- <1774fed77be11b37ce9eb4b7806f5f14539503fb.1790731662.git.me@ttaylorr.com>
On Tue, Sep 29, 2026 at 08:28:53PM -0500, Taylor Blau wrote:
Show 13 quoted lines
> When the 'repack.midxMustContainCruft' configuration is set to "false", > writing the first MIDX after such a repack may omit that cruft pack. The > new pack bypasses the `!names.nr` fallback, and there are no previous > MIDX packs for `midx_has_unknown_packs()` to check. Selecting the new > commit for bitmap coverage then fails because its reachable objects are > not all in the MIDX. > > The omission dates all the way back to 5ee86c273bf (repack: exclude > cruft pack(s) from the MIDX where possible, 2025-06-23). It relies on > geometric repacking to copy once-cruft objects with > '--stdin-packs=follow'. However, an ordinary incremental repack makes no > such guarantee. Require the MIDX to include cruft packs in that case, > even when a new pack was written.
OK. So this is a problem with just incremental repacks, but _not_ geometric repacks? And only when those incremental repacks write a midx?
If so, that makes sense to me (and the fix seems reasonable).
BTW, write_midx_incremental() does not check midx_must_contain_cruft. So I think you'd have the same problem with --write-midx=incremental. Adding that to the tests causes them to fail. I thought it might also fail with GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1, but doesn't seem to.
That's not a new problem, but just a spot where the fix doesn't extend. Not sure how important it is to do now, or if it can wait for future work.
-Peff