Re: [PATCH 3/3] test-lib: reduce verbosity of skipped tests

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

Elijah Newren <newren@gmail.com> writes:

>>   skipping test: writing bitmaps via command-line can duplicate .keep objects
>>   ok 2 # skip (--run)
>>
>> or:
>>
>>   ok 2 # skip writing bitmaps via command-line can duplicate .keep objects (--run)
>>
>> I have a slight preference towards the latter, since it keeps more of
>> the information in the TAP line, and it cuts the total line count of
>> output from skipped tests in half.
>>
>> For what it's worth, I'd also be fine with the patch as-is.
>
> I was worried that shortening it as much as I did would run into
> objections for some obscure reason.  But if no one objects, I think
> I'd also prefer your latter suggestion for shortening it even more.
> It looks like the dual output for skipped tests comes from commit
> 04ece59399 ("GIT_SKIP_TESTS: allow users to omit tests that are known
> to break", 2006-12-28) by Junio, so it'd be nice to hear his opinion
> on how much we shorten it.

I am afraid that the surrounding code has changed so heavily that
expertise as the author of 04ece593 would not count that much in the
context of today's code.  Back in the late 2006 version of the code,
text_expect_success asked test_skip to see if a test should be
skipped, and when the latter says yes (which also gave "skipping
test" to the verbose output and "skip $test_count: $1" to normal
output), test_expect_success did not even call test_ok_ or
test_failure_.  So "ok 2 # skip ..." we see in the quoted part of
your exchange above is probably a much more recent invention.

As long as we can convince ourselves that writing similar things to
fd #1 (for tap in "ok $count # skip ($why)" format) and fd #3 is
redundant and not useful, I think removing the utterance to fd #3
in this codepath may be a reasonable thing to do.

    ... goes and scans for ">&3" in test-lib.sh and
    ... test-lib-functions.sh

OK, I think we can safely lose the one we send for the "verbose"
case here and that would turn our use of fd #3 more consistent with
how it is used by other parts of the test framework.

Thanks.