Re: followRemoteHEAD management question

From: Jeff King <peff@peff.net>
Date: Jun 11, 2026, 06:01 UTC
Message-ID: <20260611060123.GA2187173@coredump.intra.peff.net>
In-Reply-To: <DJ5XE9HC5YNY.33U8AG1GX6ZP0@lfurio.us>

On Thu, Jun 11, 2026 at 12:12:54AM -0400, Matt Hunter wrote:

Show 7 quoted lines

> > Yes, this is a common problem with the remote-config namespace. Defining
> > _any_ key makes the remote "exist", even without a defined url, but that
> > isn't usually the intent.  But we can't distinguish that from the case
> > where you really do want to define a remote without a url (in which case
> > the url is the name of the remote).
> 
> I had no idea a remote like that was supported.  Interesting.

I suspect it is more of an emergent property than something that was carefully designed, but after so many years I'd hesitate to change it (at least without a big warning and deprecation period).

Show 5 quoted lines

> > I think you are on the right track. I can see arguments for or against
> > putting it in fetch.* or remote.*, so you'll have to pick one. ;)
> 
> As stated, I think putting it in fetch.* is more consistent.  I'd be
> curious to hear arguments the other way.

My initial thought is that it might affect clone as well as fetch. But I guess this feature does not kick in for clone, as it has its own logic for handling the remote-tracking HEAD. Though arguably it should be possible to configure it not to create one in the first place.

Show 10 quoted lines

> As for another design decision: I'm leaning toward omitting support for
> the "warn-if-not-$branch" value in fetch.followRemoteHEAD.
> 
> My take on that option as-documented is that it serves more as an
> acknowledgment from the user that "yes, I understand that origin has
> pointed HEAD at foo, please only warn me if it changes" as opposed to the
> user expressing that the branch "foo" is in some way special to them.
> 
> This interpretation feels very remote-dependent and doesn't make sense in
> the context of a default catch-all value to me.

Agreed. I can't think of a reason you'd want it in the global option. And if we're wrong, it is easy to add support later (versus adding it now, finding out that it creates awkward corner cases, and then having the backwards-incompatible change of ripping it out).

-Peff