From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Patrick Steinhardt <ps@pks.im>, git@vger.kernel.org
Subject: Re: [PATCH] fsck: do not loop infinitely when processing packs
Date: Tue, 24 Feb 2026 14:32:05 -0800 [thread overview]
Message-ID: <xmqq5x7lepsq.fsf@gitster.g> (raw)
In-Reply-To: <aZ4k5C_i_rK_yq68@fruit.crustytoothpaste.net> (brian m. carlson's message of "Tue, 24 Feb 2026 22:23:32 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2026-02-23 at 08:43:41, Patrick Steinhardt wrote:
>> Typically, we don't execute `find_pack_entry()` at all when verifying
>> packfiles as we iterate through objects in packfile order. We thus don't
>> have to look up objects via their object ID, but instead we do so by
>> using their packfile offset. And this mechanism will not end up in
>> `find_pack_entry()`, and thus we wouldn't update the MRU.
>
> If you're thinking about `nth_packed_object_id`, that is index (object
> ID) order, not packfile order. I actually made this mistake when
> writing the interop code and having that function operate in pack order
> breaks a surprising number of things in very subtle ways, notably
> generating multi-pack indexes.
>
> I will be sending a patch in the future documenting that requirement
> clearly.
>
>> I've got a couple patches in the making that'll fix this.
>
> I'm happy to drop this patch in favour of yours. Thanks for a quick
> response.
OK, so I'll retire your fef2a726 (fsck: do not loop infinitely when
processing packs, 2026-02-22) and replace it with the four-patch
series:
26fc7b59cd t/helper: improve "genrandom" test helper
10a6762719 object-file: adapt `stream_object_signature()` to take a stream
41b42e3527 packfile: expose function to read object stream for an offset
13eb65d366 pack-check: fix verification of large objects
Thanks.
prev parent reply other threads:[~2026-02-24 22:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-22 18:37 [PATCH] fsck: do not loop infinitely when processing packs brian m. carlson
2026-02-22 22:39 ` Junio C Hamano
2026-02-22 23:07 ` brian m. carlson
2026-02-23 7:12 ` Jeff King
2026-02-23 8:46 ` Patrick Steinhardt
2026-02-23 9:25 ` Jeff King
2026-02-23 9:36 ` Patrick Steinhardt
2026-02-23 9:46 ` Jeff King
2026-02-23 15:49 ` Junio C Hamano
2026-02-23 8:43 ` Patrick Steinhardt
2026-02-23 9:27 ` Jeff King
2026-02-23 9:53 ` Patrick Steinhardt
2026-02-24 22:23 ` brian m. carlson
2026-02-24 22:32 ` Junio C Hamano [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=xmqq5x7lepsq.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=sandals@crustytoothpaste.net \
/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.