Re: [PATCH v2] pull: handle --log=<n>

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> Hi Paul,
>
> On 2015-05-18 15:39, Paul Tan wrote:
>
>> diff --git a/t/t5524-pull-msg.sh b/t/t5524-pull-msg.sh
>> index 8cccecc..eebb8c9 100755
>> --- a/t/t5524-pull-msg.sh
>> +++ b/t/t5524-pull-msg.sh
>> @@ -17,6 +17,9 @@ test_expect_success setup '
>>  		git commit -m "add bfile"
>>  	) &&
>>  	test_tick && test_tick &&
>> +	echo "second" >afile &&
>> +	git add afile &&
>> +	git commit -m "second commit" &&
>>  	echo "original $dollar" >afile &&
>>  	git add afile &&
>
> I completely forgot to send a mail last time where I wanted to mention
> the test_commit function. I *think* that above invocation is
> equivalent to
>
>     test_commit "second commit" afile second
>
> with the additional benefit that `test_tick` is called
> automatically. Maybe you want to use that more concise function call?

Sounds like a good idea especially when you are testing commands
that does not do things to tags implicitly.

I have been in love-hate relation with test_commit for a long time.
It is very nice that it gives us ticks (i.e. reproducible object
names) automatically and reduces the chance for new tests to forget
to do so, but I found it extremely annoying that it wants to always
add a light-weight tag to every commit it creates.

I suspect that this design decision largely comes from the fact that
back then we did not exactly trust the syntax like "master~3" and
wanted to have a set of fixed points, but often these auto-generated
tags get in the way by either contaminating the refs namespaces (and
we are testing pull here, which worries me that test authors need to
be aware that these tags may be transferred to the destination) or
anchoring the objects in the object database (e.g. when writing
"reset --hard branch branch~3 && prune" tests, you need to remember
to kill these tags).

So I dunno.  I really wish test_commit didn't create tags and either
left the tagging to the calling script.