followRemoteHEAD management question

Hello git list,

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

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.

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.

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

Thanks