Re: followRemoteHEAD management question

From: Jeff King <peff@peff.net>
Date: Jun 8, 2026, 23:49 UTC
Message-ID: <20260608234946.GB358144@coredump.intra.peff.net>
In-Reply-To: <DJ19CI50W6UH.17QLIBNTXBWXU@lfurio.us>

On Fri, Jun 05, 2026 at 12:31:30PM -0400, Matt Hunter wrote:

Show 6 quoted lines

> In the past, I've preferred to run 'git remote set-head <name> -d' when
> setting up a new repository, since I generally have an awareness of what
> the remote default branch is, and I don't like seeing them in branch
> listings or git-log annotations.  They are especially noisy to me if I
> have multiple remotes.  It's possible this config is ill-advised - I
> would love to be educated if so...

No, it's perfectly reasonable. Being able to refer to "origin" to mean "origin/HEAD" is sometimes handy, but if you don't use it, there's no reason to set up the symref in the first place.

Show 8 quoted lines

> However, since b7f7d16562c3 (fetch: add configuration for set_head
> behaviour), these changes are undone by every 'git fetch'.
> 
> The topic mentioned above (merged in a1f34d595503) adds a new
> configuration key 'remote.<name>.followRemoteHEAD'.  I'm assuming that
> the intended use for followRemoteHEAD is really only in local /
> per-repository config, since trying to apply it to my personal
> .gitconfig has some odd behavior.

I think this is a gap in the new feature's implementation. It added per-remote config, but there is no global config to fall back to (e.g., the way that remote.*.prune falls back to fetch.prune). There should be a fetch.followRemoteHEAD option (or perhaps remote.followRemoteHEAD).

Show 7 quoted lines

> The <name> in the key template does not accept a wildcard, so I must
> list out each of the common remote names I use across different
> repositories.  Since many of my repos don't actually have remotes
> established for all of these names, they pick up a kind of half-baked
> definition for each of them as git performs its config parsing.  For
> instance, a name will appear under 'git remote -v', but it won't
> have any actual properties configured.

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).

Show 8 quoted lines

> Is there another solution in place I've missed?  If not, would there be
> any opposition to a new key like 'remote.followRemoteHEAD' which serves
> to provide a default value for any remote that doesn't have its own
> 'remote.<name>.followRemoteHEAD' key?
> 
> I've started scouting out changes to make for such a patch.  It's not
> ready yet, but I figured I would throw this question out in case an easy
> answer can save the effort.

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. ;)

-Peff