Junio C Hamano <gitster@xxxxxxxxx> writes:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
>
>> Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>
>> ---
>> t/t7508-status.sh | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
>> index 8ed5788..4989e98 100755
>> --- a/t/t7508-status.sh
>> +++ b/t/t7508-status.sh
>> @@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' '
>> test_i18ncmp expect output
>> '
>>
>> +test_expect_success 'status -v' '
>> + git diff --cached >>expect &&
>
> This makes the test rely on the previous one succeeding. Do we
> care, or is reproducing what ought to be in 'expect' at this step
> too expensive?
Ahh, OK. The way the existing tests prepare 'expect' is "by hand".
So I think what is wrong with this new test is not that relies on
the current contents of 'expect', but that it modifies it (imagine
being a merge/patch monkey who has to accept this change while a
change from somebody else that wants to add another test that relies
on the original 'expect' intact and then have to scratch his or her
head when the two topics are merged, wondering why the latter test
starts failing).
Perhaps
( cat expect && git diff --cached ) >expect-with-v &&
git status -v >actual &&
test_cmp expect-with-v actual
or something?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html