Thread (49 messages) flat view 49 messages, 6 authors, 5d ago

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

From: Jeff King <hidden>
Date: 2026-08-24 07:03:18

On Mon, Aug 24, 2026 at 07:40:22AM +0200, Patrick Steinhardt wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help