Re: [PATCH] t6423: fix suppression of Git’s exit code in tests

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 3, 2025, 00:04 UTC
Message-ID: <xmqq34gv3nch.fsf@gitster.g>
In-Reply-To: <CAPig+cSBi05Kq1ohxQJ8BwTsis++fAAaVCd8Ep8k=8cLS74jsw@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 16 quoted lines

> I was curious if the project has a preference between `uniq filename`
> and `uniq <filename`, but apparently we haven't:
>
>     % git grep 'uniq <' -- t | wc -l
>     2
>     git grep 'uniq [a-z0-9]' -- t | wc -l
>     2
>
> Though there does seem to be a global preference in the project to
> specify the filename directly to the command rather than redirecting
> from stdin. For instance:
>
>     % git grep 'sort <' -- t | wc -l
>     54
>     % git grep 'sort [a-z0-9]' -- t | wc -l
>     140

Have you inspected the hits from these grep runs?

    $ git grep -c 'sort [a-z0-9]' -- t/t7004-tag.sh
    t/t7004-tag.sh:17

Among 17 of them, 15 are on test titles.

    $ git grep -c '^test_expect_[sf].*sort [a-z0-9]' -- t/t7004-tag.sh
    t/t7004-tag.sh:15

So the above numbers are totally unreliable as a guide, I am afraid.

It is probably better to use sort/uniq without input redirection because your

    $ sort/uniq input >output

can be easily extended to

    $ sort/uniq input-a input-b input-c >output

but

    $ sort/uniq <input >output

cannot be extended the same way, and you'd end up doing nonsense pipe like this:

    $ cat input-a input-b input-c | sort >output

which is a no-no.

In reality, however, we are not all that logical.

    $ git grep -e '^[ 	]*sort [a-z0-9][-a-z0-9]* ' -- t | wc -l
    46
    $ git grep -e '^[ 	]*sort <' -- t | wc -l
    51

with "s/sort/uniq/", the numbers are 0 vs 1.

There are a handful of sort invocations that take their input from redirected <<HEREDOC included in the latter number, but the overall picture does not change with them excluded.