Johannes Schindelin <johannes.schindelin@xxxxxx> 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. -- 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