From: Matt Hunter Date: Fri, 05 Jun 2026 16:31:30 GMT Subject: followRemoteHEAD management question Message-ID: Hello git list, 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... 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. 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. I'd like to add a line to my config somewhere that can globally restore the old behavior in this context, eg: git config --global remote.*.followRemoteHEAD never instead of adding individual entries to each project's .git/config. 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. Thanks