Re: [PATCH 2/3] t5521 (pull-options): use test_commit() where appropriate

[Ramkumar Ramachandra <artagnon@gmail.com>]

Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> test_commit() is a well-defined function in test-lib-functions.sh that
>> allows you to create commits with a terse syntax.  Prefer using it
>> over creating commits by hand.
>>
>> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
>> ---
>>  t/t5521-pull-options.sh | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh
>> index 1b06691..4a804f0 100755
>> --- a/t/t5521-pull-options.sh
>> +++ b/t/t5521-pull-options.sh
>> @@ -7,8 +7,8 @@ test_description='pull options'
>>  test_expect_success 'setup' '
>>       mkdir parent &&
>>       (cd parent && git init &&
>> -      echo one >file && git add file &&
>> -      git commit -m one)
>> +      test_commit "one" file "one"
>> +     )
>>  '
>
> In this test script perhaps it is OK, but I'd prefer people being
> careful *not* to use test_commit in tests that involve refs (i.e.
> pushing, pulling, ls-remote, for-each-ref, describe...) and paths
> (i.e.  ls-files, diff, ...).

Okay.

> There is one good point in the helper: it creates a commit with a
> predictable timestamp.

Yes, test_tick.  I've noticed that several tests call test_tick by
hand before invoking "git commit".

> But it does a lot other *bad* things than that single good thing.
> It adds a new path, and adds a new tag; neither of which is not
> desirable in many circumstances.
>
> A better future direction would be to first make these "frill"
> features into options to test_commit helper, fix the users that
> depend on these additional tags and stuff to explicitly ask for
> them, and then start advocating it for wider use, I think.

Agreed.  In fact, the commit message is constrained, because of this;
you can't create a commit with a commit message involving spaces,
because that would result in an invalid tag name.