Re: [PATCH v4 1/1] commit-graph.c: no lazy fetch in lookup_commit_in_graph()

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 11, 2022, 20:17 UTC
Message-ID: <xmqqk08jo147.fsf@gitster.g>
In-Reply-To: <Ysw9LmBFGbRy9L7c@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 19 quoted lines

>> 512 is probably OK in CI in an isolated environment but is too low on a
>> typical "What you mean I'm not working? I'm waiting for the test run!"
>> developper workstation.
>> 
>> Conversely, which number would be too high to catch what the test is
>> supposed to catch? Does it incur a big performance penalty to go as high
>> as possible?
>
> This bit me, too. It works if I run it standalone:
>
>   $ ./t5330-no-lazy-fetch-with-commit-graph.sh 
>   ok 1 - setup: prepare a repository with a commit
>   ok 2 - setup: prepare a repository with commit-graph contains the commit
>   ok 3 - setup: change the alternates to what without the commit
>   ok 4 - fetch any commit from promisor with the usage of the commit graph
>   # passed all 4 test(s)
>
> but it fails when I run the whole test suite with "prove -j32". Or even
> easier, just run it under "--stress":

Understandable. I am usually on a datacentre VM without graphical UI so the process count there is much lower than on a typical developer workstation.

I wonder if we can just run the test without any limit? If in an unattended CI situation, hopefully they will kick the job out due to quota, and on a developer workstation, there may be processes killed left and right, but that is only when the "infinite respawning" bug reappears.