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

[Taylor Blau <me@ttaylorr.com>]

On Thu, Mar 13, 2025 at 05:26:41AM -0700, Junio C Hamano wrote:
> 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.

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