Re: [PATCH 2/2] packfile: recover when a multi-pack-index names a removed pack

From: Jeff King <peff@peff.net>
Date: Aug 24, 2026, 07:03 UTC
Message-ID: <20260824070317.GB149254@coredump.intra.peff.net>
In-Reply-To: <aovZRjcIbAUqswFT@pks.im>

On Mon, Aug 24, 2026 at 07:40:22AM +0200, Patrick Steinhardt wrote:

Show 8 quoted lines

> > This is all assuming the fallback is worth pursuing. I'm still puzzled
> > why this specific case would matter when we have the same (already
> > solved) problem of reading a regular .idx whose .pack has gone away.
> 
> I've tried to clarify in a parallel message already, but the issue is
> that we skip over any packfiles that covered by a MIDX when doing the
> lookup. So any secondary packfiles that contain the object would be
> completely ignored, and that's why we don't find the object there.

Yes, thanks. Your other message cleared it up for me.

> But this mail here suggests an alternative fix: instead of re-scanning
> all packfiles like the patch proposes, wouldn't the proper fix be to not
> ignore _all_ MIDX'd packs, but only the pack that _should_ have
> contained the object?

Do you mean in the main code path, or in the fallback?

In the main code path we definitely don't want to do this. Imagine we have a midx that covers a million packs, and says object X is in pack P. A simultaneous writer deletes P and rewrites the midx, and the object is now in a new pack Q (which might be covered by the new midx, but we don't know because we're working with the stale one).

We definitely want to look in Q for the object after the midx can't find it. But we probably don't want to immediately search in the other million midx packs. Most objects won't have such a duplicate and the search is fruitless.

-Peff