Re: [PATCH 06/18] chainlint.pl: validate test scripts in parallel

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Nov 21, 2022, 19:00 UTC
Message-ID: <CAPig+cQEdidB4YHm9OiyOUe8mbTPBajjX5t-_6ZJVwRykXkqmg@mail.gmail.com>
In-Reply-To: <Y3vI99ZiNdXddX8C@coredump.intra.peff.net>

On Mon, Nov 21, 2022 at 1:52 PM Jeff King <peff@peff.net> wrote:

Show 12 quoted lines

> On Mon, Nov 21, 2022 at 01:47:42PM -0500, Eric Sunshine wrote:
> > 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.)

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