On Thu, May 24, 2018 at 3:05 AM, SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
>> --- 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!
