Re: [PATCH v2 0/3] builtin/repack: avoid rewriting up-to-date MIDX
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Dec 12, 2025, 07:33 UTC
- Message-ID
- <aTvFOlhtPHgWQC5L@pks.im>
- In-Reply-To
- <xmqqsedhe78q.fsf@gitster.g>
On Thu, Dec 11, 2025 at 05:46:13PM +0900, Junio C Hamano wrote:
Show 31 quoted lines
> This and Taylor's incremental part 3.2 have a slight conflict in
> that this topic factors away the logic to compute if we need
> recomputing MIDX while the other one tweaks with yet another flag.
>
> My tentative resolution in 'seen' looks like the attached. Sanity
> checking is very much appreciated.
>
> Thanks.
>
> diff --cc midx-write.c
> index ce459b02c3,f2dbacef4c..66c125ccb0
> --- a/midx-write.c
> +++ b/midx-write.c
> @@@ -1014,73 -1131,30 +1131,89 @@@ static void clear_midx_files(struct odb
> strbuf_release(&buf);
> }
>
> +static bool midx_needs_update(struct multi_pack_index *midx, struct write_midx_context *ctx)
> +{
> + struct strset packs = STRSET_INIT;
> + struct strbuf buf = STRBUF_INIT;
> + bool needed = true;
> +
> + /*
> + * Ignore incremental updates for now. The assumption is that any
> + * incremental update would be either empty (in which case we will bail
> + * out later) or it would actually cover at least one new pack.
> + */
> - if (ctx->incremental)
> ++ if (ctx->incremental || ctx->compact)
> + goto out;So this here is essentially the change you had to port over, which looks about right to me. The comment is becoming somewhat stale due to the change, but I don't think that's much of an issue for now.
Thanks!
Patrick