Re: A "why TAP?" manifesto

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> == It "can be parsed"
> == Human readable
> == It's trivial to produce
> == It's more flexible
> == It doesn't matter if nobody else uses it
> == Everyone uses it

I agree with all of what you said above.

But do non-human readers really want to read output from an
"--immediate" session?  Don't they rather see the whole thing?

The only "Huh?" I had with the original patch that started the
thread was that TAP output currently does not work well with the
"--verbose" option, and I've never run our tests with the
"--immediate" option without the "--verbose" option to see where and
how the first breakage happens and what is left behind in the trash
directory, i.e. to bootstrap an interactive debugging session.

But not being useful for the use case of human reader running
interactively to get the leftover state does not mean improvement
for other use cases is not welcome.

> I think if you did the legwork of trying to make those formats represent
> our "--verbose -x" output in a machine-readable way and tried to
> roundtrip that parsed output (which I have done for TAP) that you'd find
> it somewhere between "much, much harder" and "impossible" to do the same
> for those other formats in the context of our test suite.
>
> So yes, I agree that there's a lack of focus here, and we should put
> more wood behind fewer arrows in terms of making our test output
> machine-parsable.
>
> The [2] I mentioned above shows the sorts of wins we can get from that,
> i.e. emitting *only* the lines of test output relevant to the specific
> failures we had.
>
> That's really useful, and something you inherently can't do with the
> sort of approach you're going for in your [1] series.
>
> At least not without buffering the whole thing & parsing it, at which
> point you're back to square #1 in terms of fixing the sorts of issues
> noted in "Handling the long-tail of machine-readability" above.
>
> 1. https://lore.kernel.org/git/pull.1117.git.1643050574.gitgitgadget@gmail.com/
> 2. https://lore.kernel.org/git/220302.86mti87cj2.gmgdl@evledraar.gmail.com/