Re: Consensus on a new default branch name

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