Thread (1 message) 1 message, 1 author, 2026-02-24

Re: [PATCH] fsck: do not loop infinitely when processing packs

From: Junio C Hamano <hidden>
Date: 2026-02-24 22:32:08

"brian m. carlson" [off-list ref] writes:
On 2026-02-23 at 08:43:41, Patrick Steinhardt wrote:
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help