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

[Johannes Schindelin <johannes.schindelin@gmx.de>]

Hi Junio,

On 2015-05-18 20:18, Junio C Hamano wrote:

> 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.

Yeah, light-weight tags with `test_commit` can be very annoying. IIRC the reason was not because we did not trust master~3, but that it is really unreadable. You have to be a Git nerd to find those tests intuitive that refer to master~3 which later is master~17 and then after a `git reset HEAD~5^2~3` is master~1 instead. The idea was that you could refer to the commits in question by their commit message.

I guess that I should clean up this mess and remove the tagging facility. We could use the :/<subject prefix> syntax instead, for example.

Or maybe just add a --tag flag to `test_commit` and use that in all cases where the tags were actually needed. Yeah, I think I like that option best.

Ciao,
Dscho