Re: [PATCH 6/9] fetch: ask server to advertise HEAD for config-less fetch

> Jeff King <peff@peff.net> 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.