Jeff King <peff@xxxxxxxx> writes: >> 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.
