On 2026-02-22 at 22:39:57, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > diff --git a/t/t1050-large.sh b/t/t1050-large.sh
> > index 5be273611a..75e75e627c 100755
> > --- a/t/t1050-large.sh
> > +++ b/t/t1050-large.sh
> > @@ -160,6 +160,10 @@ test_expect_success 'hash-object' '
> >  	git hash-object large1
> >  '
> >  
> > +test_expect_success 'fsck does not loop forever' '
> > +	git fsck
> > +'
> > +
> >  test_expect_success 'cat-file a large file' '
> >  	git cat-file blob :large1 >/dev/null
> >  '
> 
> Wow, this is a fun test ;-).
> 
> Thanks.  Will queue.

I noticed that the code here seems to have come in with the 2.53 cycle,
so we may want to cherry-pick it to `maint` at some point if it seems
like the problem occurs often.  From what I can tell, it only occurs
when one explicitly invokes `git fsck`[0] and not on transfer, so it
shouldn't cause a DoS against server implementations.

Of course, we should wait for Patrick, who authored this code, to chime
in and lend his expertise here.  I must admit I'm not very familiar with
this area, although I had recently seen the MRU code when working on
pack index v3 (and then I thought, "is this actually the problem?").

[0] The code I saw is the `if (check_full)` branch in `cmd_fsck`, which
is obviously only invoked by the `fsck` command itself.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA