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

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

Eric Sunshine <sunshine@sunshineco.com> 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.