From: Jeff King Date: Mon, 08 Jun 2026 23:49:46 GMT Subject: Re: followRemoteHEAD management question Message-ID: <20260608234946.GB358144@coredump.intra.peff.net> In-Reply-To: On Fri, Jun 05, 2026 at 12:31:30PM -0400, Matt Hunter wrote: > In the past, I've preferred to run 'git remote set-head -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. > 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..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). > The 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). > 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..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