On Thu, Mar 20, 2025 at 03:33:44PM -0400, Eric Sunshine wrote:
> On Thu, Mar 20, 2025 at 5:36 AM Patrick Steinhardt <ps@xxxxxx> wrote:
> > A bunch of tests rely on Perl to print data in various different ways.
> > These usages fall into the following categories:
> >
> > - Print data conditionally by matching patterns. These usecases can be
> > converted to use awk(1) rather easily.
> >
> > - Print data repeatedly. These usecases can typically be converted to
> > use a combination of `test-tool genzeros` and sed(1).
> >
> > - Print data in reverse. These usecases can be converted to use
> > awk(1).
> >
> > Refactor the tests accordingly so that we can drop a couple of
> > PERL_TEST_HELPERS prerequisites.
> >
> > Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
> > ---
> > diff --git a/t/t0610-reftable-basics.sh b/t/t0610-reftable-basics.sh
> > @@ -643,12 +643,11 @@ test_expect_success 'basic: commit and list refs' '
> > -test_expect_success PERL_TEST_HELPERS 'basic: can write large commit message' '
> > +test_expect_success 'basic: can write large commit message' '
> > test_when_finished "rm -rf repo" &&
> > git init repo &&
> > - perl -e "
> > - print \"this is a long commit message\" x 50000
> > - " >commit-msg &&
> > +
> > + awk "BEGIN { for (i = 0; i < 50000; i++) print \"this is a long commit message\" }" >commit-msg &&
> > git -C repo commit --allow-empty --file=../commit-msg
> > '
>
> The original Perl version emitted the entire message as a single-line,
> whereas the awk replacement emits 50,000 lines. Was the intent of the
> original specifically to check whether it handled an extremely long
> line correctly, or was it merely checking whether an overall very
> lengthy content was handled correctly? If the former, then this
> semantic change is inconsistent with what this test wants to be
> checking; if the latter, then this semantic change is harmless.
It really only wants to check for a big message, the exact format does
not matter at all. So in theory, we could even adapt this to use
`test-tool genzeros | tr "\000" "a"` or something like that, but I
didn't want to argue why that change is okay. The fact that we now have
a newline was unintentional.
> Also, it is possible to do this entirely in shell without running an
> external program (assuming `test` and `printf` are builtins):
>
> i=0 &&
> while test $i -lt 50000
> do
> echo "this is a long commit message" &&
> i=$(($i+1)) ||
> return 1
> done &&
True, but it's significantly slower. We already use awk in many places,
so we can just as well use it here. I'll adapt the refactoring to drop
the newlines.
Patrick
