Junio C Hamano <gitster@xxxxxxxxx> writes:
> Paul Tan <pyokagan@xxxxxxxxx> writes:
>
>> So the first example would be:
>>
>> test_output "git show HEAD:file2" new
>
> Simple things like that look fine, but when a variable is involved,
> use of eval combined with the fact that the test body is inside sq,
> makes the callers unnecessarily ugly.
>
> test_expect_success 'some title' '
> var=$(...) &&
> test_output "git show \$var:file2 | sed -e \"s/$old/$new/\"" new
> '
>
> Which is the concern this shares with the other one I sent about
> counting the number of lines in the output from a command that made
> me hesitate to suggest it.
>
> So I dunno.
I actually think that "test" that compares output from command and a
constant string, and "test" that compares outputs from two commands
are lazyily written forms of these:
echo constant string >expect &&
command >actual &&
test_cmp expect actual
command1 >expect &&
command2 >actual &&
test_cmp expect actual
The examples you gave in the earlier message were
>
> test new = "$(git show HEAD:file2)"
>
> or these:
>
> test $(git rev-parse HEAD^2) = $(git rev-parse keep-merge)
>
and I suspect they match my observation.
My earlier test_output_count was probably in the same "lazy"
category. "test $(command | wc -l) = 20" is better written
as
command >output &&
test_line_count = 20 output
instead of using the hypothetical
test_output_count = 20 "command"
that evals the command argument, not only because the quoting of
'command part will become complex for real world uses, but because
the output itself would be the first thing we would want to inspect
once the command fails. For that reason, I'd rather not to add the
test_output_count I suggested earlier, so that we would encourage
the more straight-forward form, i.e.
command >output &&
test_line_count = 20 output
to be used.
--
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