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