Re: [PATCH v2 6/8] repack: track the preferred pack explicitly in MIDX write steps

From: Taylor Blau <ttaylorr@openai.com>
Date: Oct 3, 2026, 01:00 UTC
Message-ID: <asBTxLW9j2AIVlxZ@com-79390>
In-Reply-To: <20261002232834.GE834759@coredump.intra.peff.net>

On Fri, Oct 02, 2026 at 07:28:34PM -0400, Jeff King wrote:

Show 14 quoted lines

> On Wed, Sep 30, 2026 at 11:11:58PM -0500, Taylor Blau wrote:
>
> > A MIDX write step marks preferred packs in its string-list entries and
> > chooses the last marked entry when executing the step. That makes the
> > choice depend on list order, preventing the list from being sorted for
> > membership checks.
> >
> > Record the last candidate directly in the step, borrowing its name from
> > the write list. This preserves preferred-pack selection while allowing
> > the list to be sorted without changing that choice.
>
> This is certainly cleaner, though it looks like the existing code works
> by marking item->util and then doing a linear search for it. So wouldn't
> that work even after sorting?

It would if only one entry were marked, but we can mark several.

For example, when `repack_make_midx_compaction_plan()` folds multiple MIDX layers into one via a WRITE step, it marks each layer's preferred pack without clearing the earlier marks. The scan doesn't stop at the first such mark, and the last marked entry wins.

So sorting would of course preserve the marks, but may change which one comes last.

Show 8 quoted lines

> > @@ -719,7 +713,7 @@ static int repack_make_midx_compaction_plan(struct repack_write_midx_opts *opts,
> >
> >  		item = string_list_append(&step.u.write, buf.buf);
> >  		if (p->multi_pack_index || i == opts->geometry->pack_nr - 1)
> > -			item->util = (void *)1; /* mark as preferred */
> > +			step.preferred_pack = item->string;
>
> I am certainly happy to see these gross casts go away, though.

Me too ;-).

Thanks, Taylor