All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <ttaylorr@openai.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: "Taylor Blau" <me@ttaylorr.com>,
	git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"Jeff King" <peff@peff.net>, "Elijah Newren" <newren@gmail.com>,
	"SZEDER Gábor" <szeder.dev@gmail.com>
Subject: Re: [PATCH 3/3] midx-write: include packs above custom incremental base
Date: Thu, 13 Aug 2026 15:50:41 -0500	[thread overview]
Message-ID: <an4uIQA09rDCwwBp@com-79390> (raw)
In-Reply-To: <an2FAWvyfX2LuGsG@pks.im>

On Thu, Aug 13, 2026 at 10:49:05AM +0200, Patrick Steinhardt wrote:
> On Fri, Jun 12, 2026 at 04:07:14PM -0400, Taylor Blau wrote:
> > diff --git a/midx-write.c b/midx-write.c
> > index aa438775ebd..c50fdb5c6d1 100644
> > --- a/midx-write.c
> > +++ b/midx-write.c
> > @@ -133,8 +133,17 @@ static uint32_t midx_pack_perm(struct write_midx_context *ctx,
> >  static int should_include_pack(const struct write_midx_context *ctx,
> >  			       const char *file_name)
> >  {
> > +	struct multi_pack_index *m = ctx->m;
> >  	/*
> > -	 * Note that at most one of ctx->m and ctx->to_include are set,
> > +	 * When writing incrementally, ctx->m may contain layers above
> > +	 * the selected base MIDX, which must be included in the new
> > +	 * layer.
> > +	 */
> > +	if (ctx->incremental)
> > +		m = ctx->base_midx;
> > +	/*
> > +	 * Note that at most one of m and ctx->to_include are set,
>
> Is that true? With "--stdin-packs --incremental --base=<foo>" I'd expect
> that we have both set now.

That invariant holds for `ctx->m`j, but not for the local m after the
assignment above. With '--stdin-packs', `write_midx_internal()` leaves
`ctx->m` unset, but can still set `ctx->base_midx` for an incremental
write.  Once we assign `m = ctx->base_midx`, both `m` and
`ctx->to_include` can indeed be non-NULL.

The filtering still does the right thing: packs covered by the selected
base are excluded, and the remaining packs are checked against the stdin
list. But the comment is wrong, so I'll fix it.

> Okay, previously we were always checking against `ctx->m`, so we
> would exclude packs that are contained in the current MIDX. And that
> includes the case where parts of the current MIDX are supposed to be
> thrown away because we want to write a new layer that excludes all
> layers starting at the base.

On the non- '--stdin-packs' path, yes. With '--stdin-packs', `ctx->m` is
`NULL` and the old code already checks `ctx->base_midx`. The problem
appears when the previous patch starts honoring '--base' on the ordinary
write path. Since `ctx->m` still refers to the entire existing chain, it
excludes packs from layers above the selected base.

> This is fixed by instead always comparing against the base MIDX in case
> "--incremental" was passed. When the user passes "--base=none" we don't
> have any base, and consequently we'd include all packs. Otherwise, we'll
> exclude all packs that are already covered by our base, but include all
> the other ones.
>
> That feels sensible to me.

Exactly.

Thanks,
Taylor

      reply	other threads:[~2026-08-13 20:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12 20:07 [PATCH 0/3] midx: honor custom bases for incremental writes Taylor Blau
2026-06-12 20:07 ` [PATCH 1/3] t5334: expose shared `nth_line()` helper Taylor Blau
2026-08-13  8:48   ` Patrick Steinhardt
2026-08-13 19:28     ` Taylor Blau
2026-06-12 20:07 ` [PATCH 2/3] midx: pass custom '--base' through incremental writes Taylor Blau
2026-08-13  8:49   ` Patrick Steinhardt
2026-08-13 20:30     ` Taylor Blau
2026-06-12 20:07 ` [PATCH 3/3] midx-write: include packs above custom incremental base Taylor Blau
2026-08-13  8:49   ` Patrick Steinhardt
2026-08-13 20:50     ` Taylor Blau [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=an4uIQA09rDCwwBp@com-79390 \
    --to=ttaylorr@openai.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.