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
