Re: Consensus on a new default branch name

["Michal Suchánek" <msuchanek@suse.de>]

On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:
> On Mon, Jun 15, 2020 at 03:21:54PM -0600, Taylor Blau wrote:
> 
> > > Concurrently with this, GitHub, GitLab [3], and Bitbucket are working together
> > > in order to make a similar change across our respective products. Because of
> > > this, we are met with a bit of a challenge: we would like to make these changes
> > > before the next version(s) (and so need to settle on a new default branch name),
> > > but we also want to avoid a situation where the community is fractured (eg.,
> > > GitHub uses 'main', Git uses 'default', etc).
> > >
> > > A related question is whether or not we plan to change the default value of
> > > 'core.defaultBranchName' at all (once Johannes' patches land, of course). That
> > > seems to be the intent in [4], but forming consensus around this would be good,
> > > too.
> 
> My biggest concern here was trying to understand what could break.
> Having read the patches from Johannes and thought about it a lot, I have
> a pretty good handle on where Git itself cares about the name. And I
> feel pretty confident that we can make the change in a way that won't
> cause problems there (and in fact, I think some of the code will be
> made more robust by relying on HEAD more appropriately).
> 
> There's a more open question of what _else_ will break in the ecosystem.
> I.e., what other tools and scripts did people write "master" in that
> we'll never even see, and they will eventually need to update. And there
> I think we need to be respectful of our users and their time. Obviously
> stopping at configurability is the least risky thing there. But it's
> clear that a lot of projects are interested in changing their names, so
> tools will have to deal with a world where various repos will have
> different HEAD names.
> 
> By moving the default, we do push some repos into a name change that
> might otherwise have remained oblivious (e.g., if your org has a custom
> script that nobody else will see, and nobody in your org has an interest
> in changing their repo HEADs, you might never need to update your
> scripts). We can help with that by:
> 
>   - clearly communicating the timetable for the change, and giving lots
>     of opportunity for people to consider whether their scripts might
>     need updating (again, I think in many cases these updates actually
>     make the tools more robust)
> 
>   - giving an escape hatch to restore the old behavior, which Johannes'
>     patches certainly do
> 
> Both of which I think everybody is on board with. I won't claim that
> changing the default won't cause _any_ disruption, but it seems to me to
> be on par with other changes we've made (and is being handled similarly
> carefully). So I think I'm in favor.
> 
> > > My interpretation thus far is that 'main' is the planned replacement for
> > > 'master'. Consensus seems to have formed around this name [5], but if that's
> > > incorrect--or there are yet-unvoiced opinions that you would like to share--now
> > > is the time to discuss further.
> 
> My opinion is that "main" is the best suggestion I've heard.

See also
https://lore.kernel.org/git/20200616210701.22924-1-zeevriend@gmail.com/