On Mon, Nov 21, 2022 at 02:00:41PM -0500, Eric Sunshine wrote:

On Mon, Nov 21, 2022 at 1:52 PM Jeff King [off-list ref] wrote:

quoted

On Mon, Nov 21, 2022 at 01:47:42PM -0500, Eric Sunshine wrote:

quoted

I think Ævar's use-case for `make` parallelization was to speed up
git-bisect runs. But thinking about it now, the likelihood of "lint"
problems cropping up during a git-bisect run is effectively nil, in
which case setting GIT_TEST_CHAIN_LINT=1 should be a perfectly
appropriate way to take linting out of the equation when bisecting.

Yes. It's also dumb to run a straight "make test" while bisecting in the
first place, because you are going to run a zillion tests that aren't
relevant to your bisection. Bisecting on "cd t && ./test-that-fails" is
faster, at which point you're only running the one lint process (and if
it really bothers you, you can disable chain lint as you suggest).

I think I misspoke. Dredging up old memories, I think Ævar's use-case
is that he now runs:

    git rebase -i --exec 'make test' ...

in order to ensure that the entire test suite passes for _every_ patch
in a series. (This is due to him having missed a runtime breakage by
only running "make test" after the final patch in a series was
applied, when the breakage was only temporary -- added by one patch,
but resolved by some other later patch.)

Yeah, I do that sometimes, too, especially when heavy refactoring is
involved.

Even so, GIT_TEST_CHAIN_LINT=0 should be appropriate here too.

Agreed. But also, my original point stands. If you are running 10 CPU
minutes of tests, then a few CPU seconds of linting is not really that
important.

-Peff