Re: [PATCH 2/5] t6036, t6042: use test_line_count instead of wc -l

From: Elijah Newren <newren@gmail.com>
Date: May 24, 2018, 17:03 UTC
Message-ID: <CABPp-BGS27ScX7R7GUv6oEHdynjWOzgeoYvS-759wh936-APWA@mail.gmail.com>
In-Reply-To: <20180524100507.32305-1-szeder.dev@gmail.com>

On Thu, May 24, 2018 at 3:05 AM, SZEDER Gábor <szeder.dev@gmail.com> wrote:

Show 28 quoted lines

>> --- a/t/t6036-recursive-corner-cases.sh
>> +++ b/t/t6036-recursive-corner-cases.sh
>> @@ -65,9 +65,12 @@ test_expect_success 'merge simple rename+criss-cross with no modifications' '
>>
>>               test_must_fail git merge -s recursive R2^0 &&
>>
>> -             test 2 = $(git ls-files -s | wc -l) &&
>> -             test 2 = $(git ls-files -u | wc -l) &&
>> -             test 2 = $(git ls-files -o | wc -l) &&
>
> Here 'git ls-files -o' should have listed two untracked files ...
>
>> +             git ls-files -s >out &&
>> +             test_line_count = 2 out &&
>> +             git ls-files -u >out &&
>> +             test_line_count = 2 out &&
>> +             git ls-files -o >out &&
>> +             test_line_count = 3 out &&
>
> ... but now you expect it to list three.  I was about to point out the
> typo, but then noticed that you expect it to list one more untracked
> file than before in all subsequent tests...  now that can't be just a
> typo, can it?
>
> Please mention in the commit message that when using an intermediate
> file to store the output, 'git ls-files -o' will list that file, too,
> that's why the number of expected untracked files had to be adjusted;
> so future readers won't have to figure this out themselves.

How does adding the following to the commit message sound?

    Changing to use test_line_count means using an intermediate file to store
    the output, which means that 'git ls-files -o' will have an additional
    file to list, which means that the number of lines expected in some tests
    will therefore change as well (unless the same intermediate file was used
    to capture the output of a previous command).

I'll include that in my next roll of the series after waiting for any other fixups folks point out. Sorry for the trouble.

As always, thanks for taking a look!