Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>>
>> > Let's show the output so it's clear why it failed.
>> >
>> > Signed-off-by: Felipe Contreras <felipe.contreras@xxxxxxxxx>
>> > ---
>> > t/t3400-rebase.sh | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
>> > index b58fa1a..fb39531 100755
>> > --- a/t/t3400-rebase.sh
>> > +++ b/t/t3400-rebase.sh
>> > @@ -185,6 +185,7 @@ test_expect_success 'default to @{upstream} when upstream arg is missing' '
>> > test_expect_success 'rebase -q is quiet' '
>> > git checkout -b quiet topic &&
>> > git rebase -q master >output.out 2>&1 &&
>> > + cat output.out &&
>> > test ! -s output.out
>> > '
>>
>> It is one thing to avoid squelching output that naturally comes out
>> of command being tested unnecessarily, so that "./txxxx-*.sh -v"
>> output can be used for debugging. I however am not sure if adding
>> "cat" to random places like this is a productive direction for us to
>> go in.
>>
>> A more preferrable alternative may be adding something like this to
>> test-lib.sh and call it from here and elsewhere (there are about 50
>> places that do "test ! -s <filename>"), perhaps?
>>
>> test_must_be_an_empty_file () {
>> if test -s "$1"
>> then
>> cat "$1"
>> false
>> fi
>> }
>
> Perhaps, but I'm not interested. I'm tired of obvious fixes getting rejected
> for hypothetical "ideal" situations that we'll never reach.
That's too bad. Addition of "cat" where there does not need one is
clearly not an obvious fix anyway.
--
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