Re: [PATCH] chainlint.pl: recognize test bodies defined via heredoc
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Jul 8, 2024, 19:46 UTC
- Message-ID
- <CAPig+cRzJXPa07wBXibCjfZ_uYtbAnRnOsXFrbMbCqRfwSxszg@mail.gmail.com>
- In-Reply-To
- <20240708090837.GD819809@coredump.intra.peff.net>
On Mon, Jul 8, 2024 at 5:08 AM Jeff King <peff@peff.net> wrote:
Show 12 quoted lines
> 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@mail.gmail.com/ > > 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.
Show 5 quoted lines
> 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.