Re: Consensus on a new default branch name

[Jeff King <peff@peff.net>]

On Tue, Jun 16, 2020 at 05:52:52PM +0300, Oleg wrote:

> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:
> > 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
> 
> Jeff, where do you get your statistics? github, for example, have around
> 100 million repos. How many of them want to do it?

Not statistics, but anecdotally, many major projects and communities
have expressed interest in switching. Some of them are listed here:

  https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/

I don't think 100 million is the right number to think about. Many of
those aren't active, or aren't collaborative. A project like Chrome
changing their branch name has a much bigger impact than somebody's
homework repo with three commits.

I was curious about some raw numbers, though, so I picked a random
sample of ~25k GitHub repositories that had been pushed to in the last
30 days.  About 6% have a default branch name besides "master". There's
a long tail of names. "develop", "dev", and "development" were the most
common (and likely have been that way for a while due to documents like
git-flow). Only about ~0.12% were "main" right now, but that name has
also only been discussed for about a week.

But it seems to me that with 6% non-master names, most tools are going
to run into these cases sooner or later, and have to deal with it. I'd
be much more worried about one-off scripts that see a small, non-uniform
set of repositories.

I'm also worried about documentation. There's 15 years of information
floating around the Internet that mention "master". But it would
certainly not be the first time that documentation has bit-rotted.
There's a human cost there. On the other hand, some people have
expressed that "main" might be more clear than "master", baggage aside,
so it could be an improvement in that sense. I don't have an opinion
there, having internalized Git's terminology many years ago.

> I have a better suggestion, imho. Let's make "master" a default name. Thus:
> 
> 1. we willn't break utilities and user hopes; this is a backward compatibility.
> 2. we will see how many projects really need this "feature".
> 
> I think backward compatibility is a reasonable and useful thing. And if this is
> not a political-driven changes, i see no technical reason to not do so.

I think it's clear that this _is_ a politically-driven change. It is not
helping the software in any technical way to change the name. The
question is whether the more abstract benefits to people are worth the
potential costs.

But I don't think anybody has been able to quantify the benefits in a
meaningful way. Or at least a way that everyone agrees on.

-Peff