On Mon, Jul 8, 2024 at 5:08 AM Jeff King <peff@xxxxxxxx> wrote: > On Sun, Jul 07, 2024 at 11:51:15PM -0400, Eric Sunshine wrote: > > Given the way the Makefile currently concatenates all the self-tests, > > it would indeed be a nightmare to retain the line numbers. In the long > > run, we probably ought someday to adopt Ævar's idea of checking the > > self-test files individually[*] rather than en masse. With that > > approach, it may make sense to revisit whether or not line numbers > > should be present in the "expected" files. > > > > [*] https://lore.kernel.org/git/CAPig+cSBjsosRqoAafYN94Cco8+7SdUt0ND_jHS+jVPoM4K0JA@xxxxxxxxxxxxxx/ > > I took a look at running each test individually. It's surprisingly quite > a bit slower! About 4s instead of 200ms. I'm not surprised. As currently implemented, `make test` chainlints the self-tests and the Git test scripts unconditionally, even if none of them have changed. As I understand it, Ævar idea was that the costly initial `make test` would be offset by subsequent `make test` invocations since `make` will only recheck the self-test files and Git test scripts if they have been changed. His particular use-case, as I recall, was when running the full `make test` repeatedly, such as with `git rebase --exec 'make test' HEAD~n` to ensure that the entire test suite passes for each patch of a multi-patch series prior to submitting the series; the repeated cost of linting unchanged files adds up, especially when the series is long. > There's a bit of low-hanging > fruit to get it down to ~1.7s (which I'll include in my series). But in > the end I punted on that for now, but did add line-number checks. Each > expect file just knows its own numbers, and I use a bit of perl to > handle the running offset. Okay.
