On Thu, Mar 13, 2025 at 05:26:41AM -0700, Junio C Hamano wrote: > 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. I don't disagree, but converting the 2,570 instances of 'test_commit' that I have in my tree would be difficult to do without disrupting lots of in-flight work ;-). Thanks, Taylor
