On Mon, Nov 21, 2022 at 02:00:41PM -0500, Eric Sunshine wrote: > On Mon, Nov 21, 2022 at 1:52 PM Jeff King <peff@xxxxxxxx> wrote: > > 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.) 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
