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