Subject: Re: [PATCH] t6423: fix suppression of Git’sexit code in tests

From: Junio C Hamano <[email-masked]>
Date: Sun, 02 Feb 2025 16:04:30 -0800

Eric Sunshine <[email-masked]> writes:

> 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.