Re: [PATCH 00/28] Use main as default branch name

[Jonathan Nieder <jrnieder@gmail.com>]

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