Hi, Jeff King wrote: > On Tue, Nov 17, 2020 at 07:45:21PM -0600, Felipe Contreras wrote: >> Jeff King wrote: >>> Yes, I have run into that, and it's definitely annoying. The >>> refs/remotes/<remote>/HEAD symref is created by clone, but is not >>> updated by "fetch". That's intentional, because it's supposed to >>> represent a local choice (that is merely seeded by the remote side). But >>> it seems like adding it if it's missing might be reasonable. >> >> The equivalent of this choice is in "git remote add -m": >> >> With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` >> is set up to point at remote's `<master>` branch. See also the >> set-head command. > > Wow, I'm not sure how that option escaped my notice for all these years. > Of course it would be much more useful if it pulled the value from the > remote HEAD (but again, unless we use "-f" we are not contacting the > remote at all). When would I want this implicit "set-head -a" and *not* want "-f"? [...] >> Presumably if we want to avoid the term "master", then this option >> needs to be renamed. > > Agreed that the naming is bad. That said, single-letter options often have bad names. (That's part of why these days I try to push back against single-letter options unless a flag is frequently used.) For consistency with "git clone -b", I suppose one might expect it to be "git remote add -b". Or even better, to retire the option and have people run "git remote set-head" separately. [...] > E.g., remote.origin.updateHEAD that can be set to one of: > > - never; do not touch it > > - create-if-missing; as discussed here > > - always; update it on every fetch > > And then it is just a question of what the default is. Currently it is > "never". I suspect most people would be happy with "always", but it does > break some existing flows. But perhaps "create-if-missing" is a good > medium. Thanks for bringing this up --- this is something I had been interested in as well but hadn't gotten around to contacting the list about it. The default value for a config setting like this has two purposes: - it makes the config setting for affected people who have not discovered it - it provides a sensible, predictable standard behavior Those two goals are often in tension, as they were for example when setting the default for push.default. If I consider them separately: - to make as smooth a transition as possible for people who were relying on "git remote set-head", a good behavior would be to *fail the fetch* when the remote HEAD changes. That would force the user to make a choice between "never" and "always". - one way to relax that without hurting that goal too much would be to fail the fetch when the remote HEAD changes from something other than "master" or "main". That way, the common case (moving from a default to a project-appropriate setting) would work without friction, and in other cases the user could make a choice between "never" and "always". - all that said, the default that I prefer is simply "always". Like Felipe hinted, this is a simple, intuitive behavior that most people would expect. As a transition plan, I can imagine going from one of those first two to the third after some appropriate period of time has passed. What do you think? Thanks, Jonathan
