Jeff King <peff@xxxxxxxx> writes: >> Any reason to use a bona-fide "commit" here instead of "test_commit"? >> >> Not a big deal either way, of course, I'm just curious. > > Nope, I mostly just reach for "git commit" without thinking because > that's what I naturally do while debugging or exploring. > > But since you asked...;) > > I do find test_commit a bit bloated in general. It takes several > commands versus one, leaves cruft files in the working tree (that you > need to care about not using again, lest your commit fail with "no > changes"), and by default makes tags that sometimes cause confusion > about fetching, reachability, and so on. > > The one thing it does do that git-commit doesn't is increment test_tick. > That sometimes is important (if you care about traversal ordering), but > usually doesn't. > > So I dunno. Maybe I am a bad person for not using test_commit by default > and we should have a style suggestion there. FWIW, my assessment on test_commit exactly matches yours. The cruft files it creates are often not what I want, the tags left by default are even worse, and the only good thing about it is the tick support but even that does not make much of difference in many scenarios. To its defence, I _suspect_ the automated creation of default changes were useful back when there were no "allow-empty" support. But I think it outlived its usefulness.
