Consensus on a new default branch name

Consensus on a new default branch name

[Taylor Blau]

Hello,

Over the past few days or so, there has been significant discussion [1] and
patches [2] about changing the name of the default branch away from 'master' and
towards something else.

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.

So, I would like to form some consensus here as to what the new name should be,
if that is something we're committing to doing. This way, we can make this
decision now (and allow hosts to make their corresponding changes) while still
giving us on the list some time to work on the implementation across one or
more release boundaries.

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.

Thanks,
Taylor

[1]: https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/
[2]: https://lore.kernel.org/git/pull.656.v2.git.1592225416.gitgitgadget@gmail.com/
[3]: https://gitlab.com/gitlab-org/gitlab/-/issues/222204
[4]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006111610000.56@tvgsbejvaqbjf.bet/
[5]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006091126540.482@ZVAVAG-DN14RQO.ybpnyqbznva/

Re: Consensus on a new default branch name

[Santiago Torres Arias]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Mon, Jun 15, 2020 at 02:57:22PM -0600, Taylor Blau wrote:
> Hello,
> 
> Over the past few days or so, there has been significant discussion [1] and
> patches [2] about changing the name of the default branch away from 'master' and
> towards something else.

I've been refraining myself from commenting (specially with so many
passionate voices on [1]), but I'm happy that this is happening. While I
personally don't see anything offensive in 'master', I think it's
worthwhile to try to accomodate more people in the community. As always,
it's harder to identify what is bothering a particular group if you are
not part of that group. Kudos to the community (and to you Taylor) for
trying to move this topic forward in a constructive fashion.
 

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

I'm not familiar with how formal consensus is built in this community,
but take this as an explicit +1 from me.

Cheers!
-Santiago

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Consensus on a new default branch name

[Taylor Blau]

Just correcting an incorrect 'Cc:' for James Ramsay, which I am fixing
in this email (and for anybody who replies to it).

On Mon, Jun 15, 2020 at 02:57:22PM -0600, Taylor Blau wrote:
> Hello,
>
> Over the past few days or so, there has been significant discussion [1] and
> patches [2] about changing the name of the default branch away from 'master' and
> towards something else.
>
> 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.
>
> So, I would like to form some consensus here as to what the new name should be,
> if that is something we're committing to doing. This way, we can make this
> decision now (and allow hosts to make their corresponding changes) while still
> giving us on the list some time to work on the implementation across one or
> more release boundaries.
>
> 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.
>
> Thanks,
> Taylor
>
> [1]: https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/
> [2]: https://lore.kernel.org/git/pull.656.v2.git.1592225416.gitgitgadget@gmail.com/
> [3]: https://gitlab.com/gitlab-org/gitlab/-/issues/222204
> [4]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006111610000.56@tvgsbejvaqbjf.bet/
> [5]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006091126540.482@ZVAVAG-DN14RQO.ybpnyqbznva/

Thanks,
Taylor

Re: Consensus on a new default branch name

[Jeff King]

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

Re: Consensus on a new default branch name

[Oleg]

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?

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

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.

-- 
Олег Неманов (Oleg Nemanov)

Re: Consensus on a new default branch name

[Jeff King]

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

Re: Consensus on a new default branch name

[Oleg]

On Tue, Jun 16, 2020 at 12:00:05PM -0400, Jeff King wrote:
> On Tue, Jun 16, 2020 at 05:52:52PM +0300, Oleg wrote:
> > 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/

This is not "many", Jeff :-D. There is info just about *few* major projects
(i counted not more than *15*!), that also politically biased and are
intimidated.

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

Jeff, this is a discrimination ;-). And no. This isn't right. How many
repos on github is inactive? May be 20 millions? Add to 80 millions gitlab and
all another git repos from the world. I think we can easily collect around
150-200 million of active repos. Do you really think that count of developers of
these all projects be less than count of Chrome developers? Why do 15 projects
(politically biased) outweighs 200 millions of projects? Is this example of
democracy or rationale mind? May be some there is corruption :-)?

> 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

I think if you get repos from, for example, february instead of *last* 30 days,
then you will get a yet little numbers. Because the last 21 days people are
insane, if you understand me.

And even so - 6% :-D. Jeff, this is really needed thing! :-D
This small numbers show just about one thing - this is useless feature.
Of course, i talk about normal people. In any time, there are a few "not
ordinary" persons and jokers.

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

Look, now this is a problem of rare "geniuses". Why do you want to bring
these problems to all of us :-)? What did we do you?

> 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

Yes. You are absolutely right.

> question is whether the more abstract benefits to people are worth the
> potential costs.

Of course, not. This is obvious.

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

Jeff, everything is simpler. You lie to youself about it :-). *Everybody*
adequate person will say you that there are *no* benefits at all. Only
troubles, troubles and troubles. And we are already seeing this. There is no
need for a time machine. This will helps nobody. This changes willn't materialize
food for homeless and willn't protect someone from humiliation. But in current time,
when people click "like" button instead of doing real things for others and think
that they do "everything right" and this helps somebody :-), this is hard to
understand. If you would find any slave which is offended by
"master" word, then this conversation was meaningful. But now it looks like
people who have never been masters appologize to people who have never been
slaves. And are doing this, note please, in very strange manner.

Look, if you really try to make somebody life better, just image that you
have no access to git code. How can you help? Search the better way that
will really helps somebody. Don't break git. And after several monthes,
when common sense will return to us, we will look again on this "useful"
change.

-- 
Олег Неманов (Oleg Nemanov)

Re: Consensus on a new default branch name

[Konstantin Ryabitsev]

On Tue, Jun 16, 2020 at 08:11:01PM +0300, Oleg wrote:
> > 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
> 
> Yes. You are absolutely right.
> 
> > question is whether the more abstract benefits to people are worth the
> > potential costs.
> 
> Of course, not. This is obvious.

Oleg, that doesn't make it an invalid discussion point. If Git was 
written in German and the lead branch was called "refs/heads/fuhrer" 
(German word for "leader"), you'd be on the opposite side of the 
barricades arguing that this needs to be changed because it's offensive 
to many people whose immediate family members died in WW2.

And someone else would be reasonably pointing out that "fuhrer" doesn't 
mean "The Fuhrer" and nobody is even alive since then anymore, and omg, 
why is this even a discussion topic -- isn't there something more 
important everyone could work on?

Yes, it's a politically motivated change, but it's clearly important to 
quite a few people right now and their views should not be disregarded.

-K

Re: Consensus on a new default branch name

[Oleg]

On Tue, Jun 16, 2020 at 01:32:27PM -0400, Konstantin Ryabitsev wrote:
> On Tue, Jun 16, 2020 at 08:11:01PM +0300, Oleg wrote:
> > > question is whether the more abstract benefits to people are worth the
> > > potential costs.
> > 
> > Of course, not. This is obvious.
> 
> Oleg, that doesn't make it an invalid discussion point. If Git was 
> written in German and the lead branch was called "refs/heads/fuhrer" 
> (German word for "leader"), you'd be on the opposite side of the 
> barricades arguing that this needs to be changed because it's offensive 
> to many people whose immediate family members died in WW2.

No. You are wrong here :-). I'm adequate person and the case about which you
talk couldn't happen. The problems could be if instead of "fuhrer" be
"AdolfHitler". And these are completely different things. One side is the
recist and nazi whose people killed many, very many, people in the world.
And another side is a... m... "master"? What wrong with this word?

> why is this even a discussion topic -- isn't there something more 
> important everyone could work on?

Wow. I ask just the same question again and again! There are much of work, but
we do some strange changes. These changes will generate a lot of troubles to
me and other git users/admins. I don't understand why this is happening. And
why if some country have temporary internal problems all other world should
suffer and have long-term problems. If anybody can't sleep and want do some
meaningless action, they can just buy a t-shirt with the text "no masters, no
slaves" or "i'm not supporting masters" or something like this. This will be
meaningless like a default branch name change, but nobody will suffer.

> Yes, it's a politically motivated change, but it's clearly important to 
> quite a few people right now and their views should not be disregarded.

Ok. But why my and other views are disregarded? Why are this people better,
then we? Who decide this? Why do we have a such discrimination in 2020?

This is a stupid politically motivated change and in the future something
can happens again and somebody run to change something meaningless else.
That why software should stay away from politics. Software is just an
instrument. And we shouldn't break an instrument everytime something
not technically related happens.

But this is ordinary western chauvinism. And intresting thing. People which
try to looks like anti-racist behaves like a racist:

they just do something with public tool without discussion with anyone outside of
their elite circle.

At first nobody asked indians about their land and desires. First americans just
killed almost all of they. Then, americans went to Africa and made slaves from
locals. Europian countries went to Africa and Asia and made colonies with cheap
labor. Hitler didn't ask anybody about the desire to be killed - just did it.
And now the descendants of slaveholders break public tool without asking
somebody.

Years are coming, but nothing changes...


https://www.change.org/p/github-do-not-rename-the-default-branch-from-master-to-main
https://www.reddit.com/r/github/comments/h8u7fo/github_to_replace_master_with_alternative_term_to/

-- 
Олег Неманов (Oleg Nemanov)

Re: Consensus on a new default branch name

[Jeff King]

On Tue, Jun 16, 2020 at 08:11:01PM +0300, Oleg wrote:

> > 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/
> 
> This is not "many", Jeff :-D. There is info just about *few* major projects
> (i counted not more than *15*!), that also politically biased and are
> intimidated.

I didn't count them. 15 who have already said they are interested does
seem like "many" to me, especially as I'd expect more to do so as the
issue gets more attention. I don't think it matters if they're
politically biased or not. I just said they expressed interest in
switching.

But anyway. You asked what I based my statement on. I told you.

> > 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.
> 
> Jeff, this is a discrimination ;-). And no. This isn't right. How many
> repos on github is inactive? May be 20 millions? Add to 80 millions gitlab and
> all another git repos from the world. I think we can easily collect around
> 150-200 million of active repos. Do you really think that count of developers of
> these all projects be less than count of Chrome developers? Why do 15 projects
> (politically biased) outweighs 200 millions of projects? Is this example of
> democracy or rationale mind? May be some there is corruption :-)?

Please stop making strawmen. I never said that the number of Chrome
developers was higher than the number of other developers. The original
claim I made that started this portion of the thread was only that
projects have expressed interest in changing, so tools are going to deal
with seeing non-master branches (and in fact already have been).

> And even so - 6% :-D. Jeff, this is really needed thing! :-D

Again, my point wasn't that a majority of people have changed or even
would change.My point was just that a significant enough percentage of
repos use the non-default name that it's a thing tools will need to deal
with. Perhaps you think 6% isn't enough to say so, but we may just agree
to disagree there.

> > question is whether the more abstract benefits to people are worth the
> > potential costs.
> 
> Of course, not. This is obvious.

You're asserting your position without providing any argument here.
Clearly other people feel the opposite way.

To be honest, I am not sure if it the benefits outweigh the costs or
not, and I am skeptical that any kind of accurate data gathering (e.g.,
a poll of opinions) could be done at this point, both because of the
vagueness of the task and because the issue has become so charged (not
just within Git, but in the greater world). But I'm inclined to err on
the side of empathy, especially if we can keep the cost side relatively
low.

-Peff

Re: Consensus on a new default branch name

[Konstantin Ryabitsev]

On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:
> 
> 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.

What if we work on making this configurable for now, but stick with the 
legacy name until we introduce breaking sha1 changes? Almost everything 
will need to retool for those anyway (and all documentation rewritten), 
so it is reasonable to bundle these changes to happen at the same time.

-K

Re: Consensus on a new default branch name

[Santiago Torres Arias]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

On Tue, Jun 16, 2020 at 12:10:01PM -0400, Konstantin Ryabitsev wrote:
> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:
> > 
> > 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.
> 
> What if we work on making this configurable for now, but stick with the 
> legacy name until we introduce breaking sha1 changes? Almost everything 
> will need to retool for those anyway (and all documentation rewritten), 
> so it is reasonable to bundle these changes to happen at the same time.

I wonder if allowing the buildsystem to set this default value would be
a wortwhile stepping stone. This way we can test things in different
ecosystems.

Thoughts?
-Santiago

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Consensus on a new default branch name

[Jeff King]

On Tue, Jun 16, 2020 at 12:13:31PM -0400, Santiago Torres Arias wrote:

> > What if we work on making this configurable for now, but stick with the 
> > legacy name until we introduce breaking sha1 changes? Almost everything 
> > will need to retool for those anyway (and all documentation rewritten), 
> > so it is reasonable to bundle these changes to happen at the same time.
> 
> I wonder if allowing the buildsystem to set this default value would be
> a wortwhile stepping stone. This way we can test things in different
> ecosystems.

If you mean allowing "make DEFAULT_BRANCH_NAME=foo", that seems
reasonable to me. Though the tests likely wouldn't run in that case
(unless we are planning to leave the test-environment-munging bit in
place forever, I suppose).

-Peff

RE: Consensus on a new default branch name

[Jason Pyeron]

> -----Original Message-----
> From: Konstantin Ryabitsev
> Sent: Tuesday, June 16, 2020 12:10 PM
> 
> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:
> >
> > 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.
> 
> What if we work on making this configurable for now, but stick with the
> legacy name until we introduce breaking sha1 changes? Almost everything
> will need to retool for those anyway (and all documentation rewritten),
> so it is reasonable to bundle these changes to happen at the same time.

+1 - that will also allow for a more social influence on the other tooling in the ecosystem. Projects new and existing will start to adopt a name, and that will be surveyable.

Re: Consensus on a new default branch name

[Jeff King]

On Tue, Jun 16, 2020 at 12:10:01PM -0400, Konstantin Ryabitsev wrote:

> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:
> > 
> > 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.
> 
> What if we work on making this configurable for now, but stick with the 
> legacy name until we introduce breaking sha1 changes? Almost everything 
> will need to retool for those anyway (and all documentation rewritten), 
> so it is reasonable to bundle these changes to happen at the same time.

I think that's a potential timetable we might use. It would be easier to
consider if we actually had a timetable for the sha1 changes. :)

But I certainly agree that if the timing works out favorably, switching
both defaults at once, with a big version number bump, would be nice.

I do think that the branch name change will have more far-reaching
effects on documentation than a hash change. Mostly because hashes are
random-looking garbage from a user's perspective anyway. So aside from
people dealing with hash transitions, we'll mostly just need to update
any hard-coded values in tutorials, examples, etc. Whereas I think the
word "master" creeps into a lot of more substantive discussions as a
synonym for "the main branch".

-Peff

Re: Consensus on a new default branch name

[Steve Litt]

On Tue, 16 Jun 2020 12:10:01 -0400
Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

> What if we work on making this configurable for now, but stick with
> the legacy name until we introduce breaking sha1 changes? Almost
> everything will need to retool for those anyway (and all
> documentation rewritten), so it is reasonable to bundle these changes
> to happen at the same time.

Makes perfect sense to me. No reasonable person can argue against
giving individual repository owners the ability to *easily* call their
"primary" branch anything they want.

This flame war plus the publicity it generated lets everybody know that
someday, whether in 1 month or 5 years, the default will be something
other than "master", so they'll start changing their software and
scripts to accommodate a variable instead of a hardcode, so when the
change happens, there will be minimal software disruption and minimal
hurt feelings.

SteveT

Steve Litt 
May 2020 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques

Re: Consensus on a new default branch name

[Oleg]

On Tue, Jun 16, 2020 at 01:44:49PM -0400, Steve Litt wrote:
> Makes perfect sense to me. No reasonable person can argue against
> giving individual repository owners the ability to *easily* call their
> "primary" branch anything they want.

This is great. But

> This flame war plus the publicity it generated lets everybody know that
> someday, whether in 1 month or 5 years, the default will be something
> other than "master", so they'll start changing their software and
> scripts to accommodate a variable instead of a hardcode, so when the
> change happens, there will be minimal software disruption and minimal
> hurt feelings.

this is not. Damn. Did you see what people say here? Why are you even
forcing people to do this? Just stay "master" as a default and everyone
will be happy. 

-- 
Олег Неманов (Oleg Nemanov)

Re: Consensus on a new default branch name

[Michal Suchánek]

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/

Re: Consensus on a new default branch name

[Michal Suchánek]

On Wed, Jun 17, 2020 at 08:06:17PM +0200, Michal Suchánek wrote:
> 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/

So you completely ignore this input.

That kind of gives confirmation to the naysayers that point out this is
not really about inclusivity but about US-internal politics.

If that is so be more honest and clearly say that by being based in the
US you must give way to certain activists or be potentailly subject to
terrorism from the same or more radical colleagues of the activists that
request the change.

Thanks

Michal

Re: Consensus on a new default branch name

[Jeff King]

On Wed, Jul 01, 2020 at 07:31:08PM +0200, Michal Suchánek wrote:

> > > > > 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/
> 
> So you completely ignore this input.

I didn't ignore it. I just didn't have anything useful to add after
reading your email.

If there's a potential problem with "main", I think it's worth
considering. But I have a very difficult time figuring out how to
consider all of the inputs. Personally, I don't find "main" to be a
problematic word. It has no other connotations in my personal
experience. But then the same is true of "master" as well.

Anybody in a similar position who is working on the project and might
need to form an opinion about which default word to use has to rely on
input from others. The email linked above is one data point. There are
other data points arguing that "master" is bad.

In an ideal world, we'd have a name that has no data points at all
arguing against it. But I'm not sure how feasible it is to accommodate
everybody. There seem to be enough data points arguing against "master"
that I can believe there's a non-trivial number of people who would like
the default changed to something else[1]. I had wondered if other people
might speak up against "main", but I have not seen anyone do so (neither
here, nor in other forums where the name "main" has been discussed).
That doesn't invalidate the opinion of the author above. But if we have
to choose something from among an imperfect set of options, then that
may involve picking the least-bad name.

I am open to the argument that the very people the author suggests might
be bothered by "main" might also not be well represented on this list or
in other forums discussing the change. It would be helpful if any
proponents of that argument could try to gather some evidence.

> That kind of gives confirmation to the naysayers that point out this is
> not really about inclusivity but about US-internal politics.
> 
> If that is so be more honest and clearly say that by being based in the
> US you must give way to certain activists or be potentailly subject to
> terrorism from the same or more radical colleagues of the activists that
> request the change.

I'm not sure what constructive action you're asking for here. The link
to the email above suggests that you might be arguing for a different
alternative besides "main". If so, please suggest it (or if you did
elsewhere already and I missed it: sorry, please repeat it).

If your point is to argue "you care about master but not about main,
therefore you're a hypocrite and we should change nothing". Then one,
I do not agree with that characterization, and two, I don't think that's
a very helpful addition to the conversation.

If you meant something else, please help me figure out what it is.

-Peff

[1] I'm also open to the argument that the number of data points arguing
    against "master" are inflated by well-meaning people who claim to
    speak on behalf of others. But it seems very hard to me to collect
    useful data on this kind of thing. My personal feeling is that it
    makes sense to err on the side of empathy where it's practical to do
    so.

Re: Consensus on a new default branch name

[Whinis]

Peff,

With all respect I have yet to see any evidence actually presented 
against master either. The original list makes the claim its offensive 
and everyone I have asked on other forums just says its obvious its 
offensive but cannot say how it is without resorting to `Do you not find 
enslaving humans offensive`. About all we have is twitter where you can 
easily find people saying its time to go and that changing it makes them 
feel worse as they had no problem with it and yet its being forced 
through in their name. L makes a case with research that the initial 
claim was also not made in good faith at 
https://lore.kernel.org/git/20200621195023.3881634-1-lkcl@lkcl.net/ . 
The link is also more on the master/slave depart but many of the points 
researched cover this one as well.

I like that you want to err on the side of empathy but based on how most 
of these changes have been forced through their communities I do not 
think the ones arguing for this would do the same for you. As can 
partially be seen with the claim that there is no amount of work that 
can justify continuing to use master or a host of other terms.

My personal feeling is it should not change as while many on this list 
certainly are speaking in good faith and want to help the momentum 
behind the change very much is not. While I know its not part of this 
list check out the gitlab issue where they finally opened it back up for 
discussion at https://gitlab.com/gitlab-org/gitlab/-/issues/221164 and 
it adds onto those that seem to argue for attack any who argue against. 
If a change is going to be made that will affect million of developers 
and possibly break thousands to millions of applications  I would say 
that you need a mountain of proof and not what has been seen so far.

If I may ask what is the intended result of the change if it cannot be 
measured?

-Whinis

Re: Consensus on a new default branch name

[Philip Oakley]

On 02/07/2020 13:21, Whinis wrote:
> Peff,
>
> With all respect I have yet to see any evidence actually presented
> against master either. 

The earliest claim I can find is from 2003, verified at Snopes in 2007
[1] and reported in 2003 at [1] (and elsewhere)

I would not expect that the original complaint had been withdrawn. I
don't know if the relevant US/local laws have changed.

> The original list makes the claim its offensive and everyone I have
> asked on other forums just says its obvious its offensive but cannot
> say how it is without resorting to `Do you not find enslaving humans
> offensive`. About all we have is twitter where you can easily find
> people saying its time to go and that changing it makes them feel
> worse as they had no problem with it and yet its being forced through
> in their name. L makes a case with research that the initial claim was
> also not made in good faith at
> https://lore.kernel.org/git/20200621195023.3881634-1-lkcl@lkcl.net/ .
> The link is also more on the master/slave depart but many of the
> points researched cover this one as well.

A recent blog post on racial bias in AI [2] highlighted that "Algorithms
are our opinions written in code",  just as many of our naming
conventions are implicit stand-ins for unsurfaced opinions and biases.

One area that is far more obvious in the UK, is the use of euphemisms
and innuendo, which can be grossly misused. It is quite easy to create
subtlety different phrases which actively discriminate that wouldn't be
noticed except by the careful or 'in the know' listener.  This can
easily be done with 'master' in Git.

From a comment in [3], the link [4] provides details of the association
of 'master' with 'slave' in Engineering literature, beginning in 1904
for a pendulum & clock arrangement. In electronic clock circuits it
wasn't till 1966 the use extended to flip-flop circuits, while hydraulic
master/slave cylinders started in 1959.

>
> I like that you want to err on the side of empathy but based on how
> most of these changes have been forced through their communities I do
> not think the ones arguing for this would do the same for you. As can
> partially be seen with the claim that there is no amount of work that
> can justify continuing to use master or a host of other terms.

Branch names are meant to be ephemeral is the wider Git ecosystem, so
Git should be able to allow the user to chose their own default name.

>
> My personal feeling is it should not change as while many on this list
> certainly are speaking in good faith and want to help the momentum
> behind the change very much is not. While I know its not part of this
> list check out the gitlab issue where they finally opened it back up
> for discussion at https://gitlab.com/gitlab-org/gitlab/-/issues/221164
> and it adds onto those that seem to argue for attack any who argue
> against.

The other issue is that Git doesn't do unique masters anyway. If you
have the correct commit hash you have a perfect, indistinguishable
replica of the original object - It's not a master (in the old 'version
control' sense) any more, so we don't need that name for local clone's
branch, unless it happens to be copied as the remote tracking branch. 
Though that is orthogonal to this discussion.

> If a change is going to be made that will affect million of developers
> and possibly break thousands to millions of applications

As I understand the change process, this will not be the catastrophic
change many are suggesting. Existing repositories will still continue
working. New repositories will have options for choosing the defaults.
The usual level of great care over backward compatibility is being taken. 

>   I would say that you need a mountain of proof and not what has been
> seen so far.
>
> If I may ask what is the intended result of the change if it cannot be
> measured?
>

Anyway, that's the back story, with references,  that I've been able to
track down. Hope that helps.

Philip


[1] https://www.snopes.com/fact-check/masterslave/
[2] http://news.bbc.co.uk/1/hi/technology/3243656.stm
[3]
https://dev.to/educative/understanding-racial-bias-in-machine-learning-algorithms-4cij
[4] Stable URL: http://www.jstor.com/stable/40061475  "Broken Metaphor:
The Master-Slave Analogy in Technical Literature "

Re: Consensus on a new default branch name

[Whinis]

> The earliest claim I can find is from 2003, verified at Snopes in 2007
> [1] and reported in 2003 at [1] (and elsewhere)
>
> I would not expect that the original complaint had been withdrawn. I
> don't know if the relevant US/local laws have changed.
Not exactly proof in this sense nor proof they had an actual grievance 
as someone in US law might tell you. Sadly it was rather recently a 
lawyer would go around claiming to be disabled or speak for an unnamed 
disabled citizen and sue every single restaurant they came across for 
ADA violations. Same was done recently with a Lebowits but for copyright 
law where its easy as a lawyer to sue continuously to get an easy 
settlement until you are disbarred. Even from that link the official 
that wrote the memo said

> “I do understand that this term has been an industry standard for 
> years and years and this is nothing more than a plea to vendors to see 
> what they can do,” he said. “It appears that some folks have taken 
> this a little too literally.”
>
> Sandoval said that he had already rejected a suggestion that the 
> county stop buying all equipment carrying the “master” and “slave” 
> labels and had no intention of enforcing a ban on such terms with 
> suppliers.
>
> A recent blog post on racial bias in AI [2] highlighted that "Algorithms
> are our opinions written in code",  just as many of our naming
> conventions are implicit stand-ins for unsurfaced opinions and biases.
>
There is a great deal of misunderstanding on the "bias" in AI and in AI 
in general. I think you may have linked the wrong comment as [2] goes to 
a BBC story on the same story as the snopes article. However if you are 
talking about the recent depixelator it was shown to have similar 
performance if you darkened the images. This is not a bias its a 
technological limitation as darker images have less contrast on facial 
features, its also a well known issue in photography where its difficult 
to get enough dynamic range to properly expose an image with both 
darkskin and light skin individuals. Outside of extremely expensive 
cameras that even professional photographers don't want to use the 
technology is not in the hands of people to take proper photos with the 
needed dynamic range. This is also why lighting in films and TV are so 
important.

I feel a great many people want to attribute bias due to lack of data 
whenever no bias exists.

> One area that is far more obvious in the UK, is the use of euphemisms
> and innuendo, which can be grossly misused. It is quite easy to create
> subtlety different phrases which actively discriminate that wouldn't be
> noticed except by the careful or 'in the know' listener.  This can
> easily be done with 'master' in Git.

Unless you are making some allegation that anyone using the word master 
is racists or that somehow every technical field is inherently racists I 
have no idea why you are claiming its the same as actively 
discriminating. Or maybe you are trying to say the UK using its 
euphemisms is trying to be covertly racists? It would do well to clear 
up this confusing reference as it currently could be seen as insulting 
or making implications which clearly do not exists.

>  From a comment in [3], the link [4] provides details of the association
> of 'master' with 'slave' in Engineering literature, beginning in 1904
> for a pendulum & clock arrangement. In electronic clock circuits it
> wasn't till 1966 the use extended to flip-flop circuits, while hydraulic
> master/slave cylinders started in 1959.
I am rather unsure why you are reference either. Maybe you mixed up 2 
and 3 because 3 has nothing on master or slave but as you have mentioned 
its orthogonal since git has no slave branch. 4 is a admittedly short 
paper as the author recognized that it could be its own doctoral thesis 
and only did a cursory search although many are using it as proof that 
no references exists prior to this time. It also adds its own heavy 
biases as mentioned in the paper while gill was the first to use the 
slave reference that they can find it was used for many years without 
much discussion and even when challenged it was determined it would be 
better than a much wordier alternative because it would be better 
understood. The paper also claim that Gill would be disapproving of the 
words use however has nothing to back this up considering they not only 
used the term but appearntly did so for many years afterwords at lectures.

> The other issue is that Git doesn't do unique masters anyway. If you
> have the correct commit hash you have a perfect, indistinguishable
> replica of the original object - It's not a master (in the old 'version
> control' sense) any more, so we don't need that name for local clone's
> branch, unless it happens to be copied as the remote tracking branch.
> Though that is orthogonal to this discussion.
How does each commit have a perfect indistinguishable replica of the 
original? My understanding is each commit is a record of changes 
compared to the last. As such only the first commit is truly 'perfect'

> As I understand the change process, this will not be the catastrophic
> change many are suggesting. Existing repositories will still continue
> working. New repositories will have options for choosing the defaults.
> The usual level of great care over backward compatibility is being taken.
Is it? Because it seems to be that its waved off as a necessary cost of 
changing "outdated" language.  Being that its been used now for at least 
110 years and being that its the understood vernacular and multiple 
projects and scripts assume, even if wrongly, the master branch is the 
one you should work from means changing this default is not usual great 
level of care. Certainly main seem to think its as simple as changing 
the letter and nothing will break. Sadly that rarely true

> Anyway, that's the back story, with references,  that I've been able to
> track down. Hope that helps.
Unfortuntely no as the references being asked for is who this change 
actually impacts. We could go to twitter but that has it owns biases and 
every issue on this topic outside of this mailing list is either locked 
or biases by assuming it must change and leaving out master or tainted 
due to brigading. Just based on what I have anecdotally seen however 
most of the people pushing for this change is not the affected minority 
group its claimed to help.

-Whinis

Re: Consensus on a new default branch name

[Philip Oakley]

Hi,
My key point was to pass on the references. I appreciate that US law is
a bit peculiar (to European eyes).

On 02/07/2020 22:59, Whinis wrote:
>> The earliest claim I can find is from 2003, verified at Snopes in 2007
>> [1] and reported in 2003 at [1] (and elsewhere)
>>
>> I would not expect that the original complaint had been withdrawn. I
>> don't know if the relevant US/local laws have changed.
> Not exactly proof in this sense nor proof they had an actual grievance
> as someone in US law might tell you.

The point there was that it was, at the time, a complaint that had a
response which was passed into the community.

> Sadly it was rather recently a lawyer would go around claiming to be
> disabled or speak for an unnamed disabled citizen and sue every single
> restaurant they came across for ADA violations. Same was done recently
> with a Lebowits but for copyright law where its easy as a lawyer to
> sue continuously to get an easy settlement until you are disbarred.
> Even from that link the official that wrote the memo said
>
>> “I do understand that this term has been an industry standard for
>> years and years and this is nothing more than a plea to vendors to
>> see what they can do,” he said. “It appears that some folks have
>> taken this a little too literally.”
>>
>> Sandoval said that he had already rejected a suggestion that the
>> county stop buying all equipment carrying the “master” and “slave”
>> labels and had no intention of enforcing a ban on such terms with
>> suppliers.
>>
>> A recent blog post on racial bias in AI [2] highlighted that "Algorithms
>> are our opinions written in code",  just as many of our naming
>> conventions are implicit stand-ins for unsurfaced opinions and biases.
>>
> There is a great deal of misunderstanding on the "bias" in AI and in
> AI in general. I think you may have linked the wrong comment as [2]
My error in failing to renumber that correctly.

> goes to a BBC story on the same story as the snopes article. However
> if you are talking about the recent depixelator it was shown to have
> similar performance if you darkened the images. This is not a bias its
> a technological limitation as darker images have less contrast on
> facial features, its also a well known issue in photography where its
> difficult to get enough dynamic range to properly expose an image with
> both darkskin and light skin individuals. Outside of extremely
> expensive cameras that even professional photographers don't want to
> use the technology is not in the hands of people to take proper photos
> with the needed dynamic range. This is also why lighting in films and
> TV are so important.
>
> I feel a great many people want to attribute bias due to lack of data
> whenever no bias exists.
Today an article highlighted the issues and difficulties with data sets:
https://arxiv.org/pdf/2006.16923.pdf
>
>> One area that is far more obvious in the UK, is the use of euphemisms
>> and innuendo, which can be grossly misused. It is quite easy to create
>> subtlety different phrases which actively discriminate that wouldn't be
>> noticed except by the careful or 'in the know' listener.  This can
>> easily be done with 'master' in Git.
>
> Unless you are making some allegation that anyone using the word
> master is racists 

It's the *misuse* that's racist

> or that somehow every technical field is inherently racists I have no
> idea why you are claiming its the same as actively discriminating. Or
> maybe you are trying to say the UK using its euphemisms is trying to
> be covertly racists?

Racists in the UK (and elsewhere) do use euphemisms and subtleties to
perform "vicious signalling".

> It would do well to clear up this confusing reference as it currently
> could be seen as insulting or making implications which clearly do not
> exists.
>
>>  From a comment in [3], the link [4] provides details of the association
>> of 'master' with 'slave' in Engineering literature, beginning in 1904
>> for a pendulum & clock arrangement. In electronic clock circuits it
>> wasn't till 1966 the use extended to flip-flop circuits, while hydraulic
>> master/slave cylinders started in 1959.
> I am rather unsure why you are reference either.
The original US case was with reference to the joint use of
master-slave. That Jstor article may be behind a log-in wall, so I
extracted from the essay, for immediate readers, some of the initial
uses of that term pair in engineering.

> Maybe you mixed up 2 and 3 because 3 has nothing on master or slave
> but as you have mentioned its orthogonal since git has no slave
> branch. 4 is a admittedly short paper as the author recognized that it
> could be its own doctoral thesis and only did a cursory search
> although many are using it as proof that no references exists prior to
> this time. It also adds its own heavy biases as mentioned in the paper
> while gill was the first to use the slave reference that they can find
> it was used for many years without much discussion and even when
> challenged it was determined it would be better than a much wordier
> alternative because it would be better understood. The paper also
> claim that Gill would be disapproving of the words use however has
> nothing to back this up considering they not only used the term but
> appearntly did so for many years afterwords at lectures.
>
>> The other issue is that Git doesn't do unique masters anyway. If you
>> have the correct commit hash you have a perfect, indistinguishable
>> replica of the original object - It's not a master (in the old 'version
>> control' sense) any more, so we don't need that name for local clone's
>> branch, unless it happens to be copied as the remote tracking branch.
>> Though that is orthogonal to this discussion.
> How does each commit have a perfect indistinguishable replica of the
> original?

Your a08a83db2bf27f015bec9a435f6d73e223c21c5e, my
a08a83db2bf27f015bec9a435f6d73e223c21c5e,
https://github.com/git/git/commit/a08a83db2bf27f015bec9a435f6d73e223c21c5e
: Which is the "master copy"
> My understanding is each commit is a record of changes compared to the
> last. As such only the first commit is truly 'perfect'
It's that Git is *distributed*, rather than a single central source of
truth that old version control systems used. I remember the smell of
blueprints, and of kaolin & linen master drawings (unique works of art,
protected and valued). That has all gone. It now a case of validating
the copy you have same hash. The chain of evidence has reversed.

>
>> As I understand the change process, this will not be the catastrophic
>> change many are suggesting. Existing repositories will still continue
>> working. New repositories will have options for choosing the defaults.
>> The usual level of great care over backward compatibility is being
>> taken.
> Is it? Because it seems to be that its waved off as a necessary cost
> of changing "outdated" language.  Being that its been used now for at
> least 110 years

Gits choice is only 15 years old.  There have been other changes to Git,
and the forthcoming hash change is much more of an 'impacts everyone'
change. Any direction of travel always includes some changes, generally
for the better.

> and being that its the understood vernacular and multiple projects and
> scripts assume, even if wrongly, the master branch is the one you
> should work from means changing this default is not usual great level
> of care. Certainly main seem to think its as simple as changing the
> letter and nothing will break. Sadly that rarely true
>
>> Anyway, that's the back story, with references,  that I've been able to
>> track down. Hope that helps.
> Unfortuntely no as the references being asked for is who this change
> actually impacts. We could go to twitter but that has it owns biases
> and every issue on this topic outside of this mailing list is either
> locked or biases by assuming it must change and leaving out master or
> tainted due to brigading. Just based on what I have anecdotally seen
> however most of the people pushing for this change is not the affected
> minority group its claimed to help.
>
Most progress comes through imperceptible changes, made in the
appropriate general direction.

Philip

Re: Consensus on a new default branch name

[Whinis]

> The point there was that it was, at the time, a complaint that had a
> response which was passed into the community.
Right but as is the case here of a likely either malicious requests or 
an offhand comment leading to disproportionate response just as I 
believe this started due to a wallstreet journal article inflating a 
pair of terms used for over 100 years as racists simply due to being used.

> It's the *misuse* that's racist
Are you saying using the word master is racists? Are you aware of the 
origins of the term and how far back it goes? or that mister is also a 
mutation of the same word? Cause that a rather high bar to state 
considering its use not just in programing or engineering but also 
things such as master degree and master copy. Its also rather odd 
considering that suggestion that master alone is racists from what I can 
tell started only with this git issue.

> The original US case was with reference to the joint use of
> master-slave. That Jstor article may be behind a log-in wall, so I
> extracted from the essay, for immediate readers, some of the initial
> uses of that term pair in engineering.
That's fair, I have a university subscription and have seen that article 
a few times. Its ultimately a first pass article that someone could take 
further but should in no way be used as proof that this was the first 
use of this pair. Also the pair does not exists in this case so its a 
rather odd citation.

> It's that Git is *distributed*, rather than a single central source of
> truth that old version control systems used. I remember the smell of
> blueprints, and of kaolin & linen master drawings (unique works of art,
> protected and valued). That has all gone. It now a case of validating
> the copy you have same hash. The chain of evidence has reversed.
Sure, how does that impact the use of the word master? its the branch 
name as in the branch, as described by the person that picked the name, 
of the master copy. Git being distributed has nothing todo with the branch

> Gits choice is only 15 years old.  There have been other changes to Git,
> and the forthcoming hash change is much more of an 'impacts everyone'
> change. Any direction of travel always includes some changes, generally
> for the better.
Framing moving large sections of words out of use that have been in 
common use for at least 100 years in a technical sense and has no racial 
connection or common racial usage seems a rather odd thing to consider 
progress. I would view people developing non-existent connections 
between words just as the snopes articles showed is a step backwards and 
shows a lack of education on words. If you first  thought with seeing a 
word is how can it offend someone it might be difficult to work around. 
If anything you are inflating problems that don't actually exists.


-Whinis

Re: Consensus on a new default branch name

[Jonathan Nieder]

Michal Suchánek wrote:
> On Wed, Jun 17, 2020 at 08:06:17PM +0200, Michal Suchánek wrote:

>> https://lore.kernel.org/git/20200616210701.22924-1-zeevriend@gmail.com/
>
> So you completely ignore this input.

I've done enough research to know that even within the context
discussed in that message, this is not what comes to mind when the
word "main" is used.

That said, the approach so far in the Git changes discussed here has
been to focus on configurability.  We don't only have to care about
defaults: we also need to make sure Git is adaptable enough to work
well with branch names that fit the needs of particular Git-using
projects (whether that's because they use a different language than
English or because they have chosen branch names that reflect their
workflow, or for other reasons entirely).

Thanks and hope that helps,
Jonathan

Re: Consensus on a new default branch name

[Elijah Newren]

On Mon, Jun 15, 2020 at 2:01 PM Taylor Blau <me@ttaylorr.com> wrote:
>
> So, I would like to form some consensus here as to what the new name should be,
> if that is something we're committing to doing. This way, we can make this
> decision now (and allow hosts to make their corresponding changes) while still
> giving us on the list some time to work on the implementation across one or
> more release boundaries.
>
> 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.

As I stated in the other thread[1], I'm happy 'default' isn't winning
because I think it can lead to ambiguity about the meaning of the
phrase "default branch" (particularly when someone changes HEAD on the
server to point to anything other than "refs/heads/default").  I don't
think "main branch" poses similar issues, as it's not a phrase I've
seen used that much (in contrast to "default branch").  Also,
"default" being ambiguous bothers me personally more than other terms
being ambiguous, as per my story in the other thread.  However, it's
possible that there is documentation or guides somewhere that have
used "main branch" in the past and could become ambiguous with the
proposed change, and thus would benefit from updates.

In fact, just to verify, I did a quick search of the git codebase and
found 38 uses of "default branch".  There were also 9 uses of "main
branch", but almost all of those were actually referring to a CVS
repository and importing from there which I find innocuous.  There was
one in git-log.txt that looked problematic to me, though -- it should
probably be reworded when we do the master->main renaming.

Hope that helps,
Elijah

[1] https://lore.kernel.org/git/CABPp-BF8vo_fCbM1ct0MYFhQcVmPwfq7_Q3Fd+SnM0=gVmxkrQ@mail.gmail.com/

Re: Consensus on a new default branch name

[Jeff King]

On Mon, Jun 15, 2020 at 03:38:08PM -0700, Elijah Newren wrote:

> As I stated in the other thread[1], I'm happy 'default' isn't winning
> because I think it can lead to ambiguity about the meaning of the
> phrase "default branch" (particularly when someone changes HEAD on the
> server to point to anything other than "refs/heads/default").  I don't
> think "main branch" poses similar issues, as it's not a phrase I've
> seen used that much (in contrast to "default branch").  Also,
> "default" being ambiguous bothers me personally more than other terms
> being ambiguous, as per my story in the other thread.  However, it's
> possible that there is documentation or guides somewhere that have
> used "main branch" in the past and could become ambiguous with the
> proposed change, and thus would benefit from updates.

Thanks for writing this out (I'm still catching up on list email after a
vacation, so I missed the earlier thread). It really cemented for me
that "main" is better than "default".

-Peff

Re: Consensus on a new default branch name

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Thanks for writing this out (I'm still catching up on list email after a
> vacation, so I missed the earlier thread). It really cemented for me
> that "main" is better than "default".

In any case, it makes sense to use separate words for the concept
("default" --- as in "the name given to the first branch created in
the repository by default") and the actualy value chosen for the
entity (master or main in this case).  

The statement:

    I configure in ~/.gitconfig that the default branch name for all my
    repositories to be 'main'

is much easier to read than the last 'main' replaced with 'default'.

Re: Consensus on a new default branch name

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On 2020-06-15 at 20:57:22, Taylor Blau wrote:
> 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.

I think "main" is a fine choice.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Consensus on a new default branch name

[James Ramsay]

On 16 Jun 2020, at 6:57, 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).

Avoiding inconsistency is definitely front of mind for me.

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

Based on informal surveys internally, and polling on 
https://gitlab.com/gitlab-org/gitlab/-/issues/221164, ‘main’ seems 
to be the preferred option. Using GitLab’s MECEFU (Mutually Exclusive, 
Collectively Exhaustive, Few Words, Ubiquitous Language) [1] approach to 
naming I think ‘main’ ticks all the boxes. None of the other 
proposals seem as clear.

I think Elijah’s points in other messages about the problems of 
‘default’ are particularly helpful. I would prefer to avoid that 
name.

Thanks,
James

[1]: https://about.gitlab.com/handbook/communication/#mecefu-terms

Re: Consensus on a new default branch name

[Nomen Nescio]

> Over the past few days or so, there has been significant discussion
> [1] and patches [2] about changing the name of the default branch away
> from 'master' and towards something else.

> 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.
> 
> So, I would like to form some consensus here as to what the new name
> should be,

Some interesting consensus this is trying to form... Let's look at it.

git-for-windows [1]: 76 upvotes, 490 downvotes, overwhelming consensus
in the comments rejecting the proposed change as unwarranted. Result:
comments massively moderated, even though they weren't even in majority
abusive; many dissenters blocked; thread locked, preventing further
input.

GitLab [2]: 23 upvotes, 145 downvotes, rejection in the comments.
Result: thread locked, preventing further input, and an online poll,
that doesn't even offer the option to voice support for keeping the
"master" name.

And in this mailing list: very few people from the community on behalf
of which this is done participating to give their actual opinion on
the issue, and even fewer of them actually supporting the claim that
"master" offends them and should be changed; unspecified people who
apparently believe that "master" offends people, apparently voicing
their opinions in private, which are then apparently not even relayed
but merely vaguely mentioned to us; and on the other side, people who
feel compelled to hide behind others or post anonymously to disagree,
even as their opinion is respectful and attempts to be constructive.

So not just some consensus here, quite some inclusiveness too, this
is achieving: this is put forward in the name of making things more
inclusive, but fails to bring to the table first-hand, people actually
offended by the issue, and makes disagreeing people feel unwelcome - or
enforces them and their input as unwelcome.

Several people are working on the assumption that this change would
surely make a positive impact, even if little, and would be some step
in the right direction. Several people have put forward the argument
explaining to skeptics that it can be difficult to relate to the
struggle of people from a different community without walking in their
shoes, and difficult to understand how they can feel about a certain
issue. Do people putting forward this argument, or the claim that
this community is offended by "master", are themselves part of this
community? If not, how can they be so sure to understand properly
whether and how much this truly offends that community, that they feel
in a position to best speak on their behalf?

Taylor, how do you propose to build this consensus you're talking about
on the name change? Guesswork? What sounds like it has a good ring
to it? Going with the most popular name - i.e., letting the decision
process degenerate into a popularity contest? Whoever yells the loudest,
whatever group or project has most clout? Can you propose a consensus
process that reconciles with the loud majority of commenters who
downvoted this proposal, or justifies why their arguments are not the
right decision criteria?

I know you mean well, and my question is sincere. The stated purpose is
to avoid offending people, based on the premise that some terms offend
people, so I would propose that this would be an important aspect to
correctly assess; in order to base the renaming decision on a real
assessment of what actually offends people, rather than on what some
group says could be offensive, or on some possible drawback with such or
such name that someone did or didn't think to foresee.

So, and this would follow good software development and release
management practices, but even just for the sake of appeasement with
people who think this is not a real issue, and for the sake of going
forward with a constructive process on solid grounds, I would love to
see some data that backs up, details, clarifies and quantifies the claim
that the current "master" name offends people.

I haven't seen any such data so far. All I've seen is a popular trend,
and mentions of groups or projects who have got on board with that trend
- which as I said, is hardly relevant to the merits of its premise. I
haven't seen first-hand accounts of people being offended, anecdotal
or not. I haven't seen serious studies being linked. I haven't seen
representative surveys; opinion polls, especially online, can be
completely skewed and nearly worthless, but I haven't even seen one of
those getting brought forward in support of the name change. I haven't
seen expert or authoritative opinions being brought to the debate as
such.

So I haven't seen any assessment of people being offended by "master",
which could be solved by moving from it; and I haven't seen either
any assessment of whether the change itself would in turn offend and
alienate people who think it is unwarranted, ridiculous, outrageous
and whatnot. I haven't seen any assessment of whether people who find
this proposal offensive are a loud reactionary minority, or a silent
majority. And given the stated purpose of avoiding offending people,
that would seem important to assess too.

So again, I would love to see data that backs up the claim that this
change is necessary to solve a fathomable problem, and will have the
intended impact. I would preferably love measurable and verifiable data,
but any if possible.

I have to assume that people driving this forward would care to make
sure to effect change that actually helps. If not, then you may want
to do some soul-searching; if you don't care to determine whether your
effort actually helps, then you may want to double-check that this isn't
more about virtue signalling, or slacktivism only making yourself feel
good.

And either way, as this is all happening on the public place, putting
forward that data and even just addressing these concerns and processing
this proposal properly would help to reconcile the software community
dividing over this, and strengthen the trust and credibility that
important tools and platforms hold among it.

So please show me the data.

[1]: https://github.com/git-for-windows/git/issues/2674
[2]: https://gitlab.com/gitlab-org/gitlab/-/issues/221164

Re: Consensus on a new default branch name

[Jonathan Nieder]

Hi Nomen,

Nomen Nescio wrote:

> Taylor, how do you propose to build this consensus you're talking about
> on the name change?

I'm glad you're interested in learning more about the Git development
process!

There are some open source projects that function (mostly) as a
democracy --- they build the features that those voting request.  A
famous example of this would be PHP[1].  There is something admirable
about that approach, but it is not always easy to get right.  Many
other projects have their own approaches to governance.

In Git, we make most decisions by a rough consensus of active
contributors, as judged by the maintainer.  There are times that
consensus may go in a direction that is unworkable, and the maintainer
has the ability to make a different decision during those times.  If
decision making ever goes off the rails (perhaps you've judged this to
be such a moment!), users of Git have the recourse of forking the
code; such moments have happened in some open source projects in the
past, for the better, such as the EGCS fork of GCC that was widely
used by distributors and eventually became the standard version of
GCC.

If you are looking to have more influence in the Git project, my
advice would be to become a respected contributor, by providing
patches, well thought out reviews, documentation improvements, advice
to bug reporters, or other contributions.  As others learn to trust
your feedback, you will have more influence on consensus.  Even
better, you get the immediate benefit of your own work as soon as you
do it.

I believe Taylor was also interested in another kind of consensus,
between hosting providers, but that would be likely to coincide with
what the Git project does so the difference is a bit academic.

[...]
> slacktivism

This is a very weird way to describe the people who are spending their
time to maintain Git.

Thanks and hope that helps,
Jonathan

[1] https://lwn.net/Articles/821821/

Re: Consensus on a new default branch name

[Taylor Blau]

Hi Jonathan,

On Mon, Jun 15, 2020 at 07:22:39PM -0700, Jonathan Nieder wrote:
> Hi Nomen,
>
> Nomen Nescio wrote:
>
> > Taylor, how do you propose to build this consensus you're talking about
> > on the name change?
>
> I'm glad you're interested in learning more about the Git development
> process!
>
> There are some open source projects that function (mostly) as a
> democracy --- they build the features that those voting request.  A
> famous example of this would be PHP[1].  There is something admirable
> about that approach, but it is not always easy to get right.  Many
> other projects have their own approaches to governance.
>
> In Git, we make most decisions by a rough consensus of active
> contributors, as judged by the maintainer.  There are times that
> consensus may go in a direction that is unworkable, and the maintainer
> has the ability to make a different decision during those times.  If
> decision making ever goes off the rails (perhaps you've judged this to
> be such a moment!), users of Git have the recourse of forking the
> code; such moments have happened in some open source projects in the
> past, for the better, such as the EGCS fork of GCC that was widely
> used by distributors and eventually became the standard version of
> GCC.
>
> If you are looking to have more influence in the Git project, my
> advice would be to become a respected contributor, by providing
> patches, well thought out reviews, documentation improvements, advice
> to bug reporters, or other contributions.  As others learn to trust
> your feedback, you will have more influence on consensus.  Even
> better, you get the immediate benefit of your own work as soon as you
> do it.
>
> I believe Taylor was also interested in another kind of consensus,
> between hosting providers, but that would be likely to coincide with
> what the Git project does so the difference is a bit academic.

What I am broadly interested in is a consensus among the community, so
that we don't have a variety of different names for the default branch
based on where and how you use Git. Of course, by introducing a
configuration option, some variety is to be expected, but I would like
to avoid, for example, GitHub/GitLab/Bitbucket choosing a different name
from what the Git project decides on.

> [...]
> > slacktivism
>
> This is a very weird way to describe the people who are spending their
> time to maintain Git.
>
> Thanks and hope that helps,
> Jonathan
>
> [1] https://lwn.net/Articles/821821/

Thanks,
Taylor

Re: Consensus on a new default branch name

[Jeff King]

On Mon, Jun 15, 2020 at 07:22:39PM -0700, Jonathan Nieder wrote:

> In Git, we make most decisions by a rough consensus of active
> contributors, as judged by the maintainer.[...]

Thanks for writing this out. I agree completely with how you described
the decision making process.

We do bear the responsibility to think carefully about our users, and to
respect their time, and their expectations that things don't break. But
as with any feature, it's a juggling act between stability and progress
that developers and the maintainer must deal with. Somebody might not
care about this name change, but likewise, others might not care about a
particular technical feature. At some point users have to put their
trust in Git's developers that the end product will be stable and
useful. If we break that trust too much, then forking is an option, as
you note. Our track record has been pretty good so far, and I think if
we approach this change carefully, it can continue to be.

-Peff

Re: Consensus on a new default branch name

[Anonymous Remailer (austria)]

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

I'm glad that we can agree on this point, and start giving attention to
it. Thank you, Jeff. It seems that we're still in the dark about how
helpful this change would really be, and whether its impact, if any,
would go into the right direction.

So far, the best evidence I've seen comes from people expressing that
contrary to what is alleged on their behalf, not only the term "master"
does not offend them, but it is in fact this renaming proposal that
comes off as racist and uncomfortable to them; and from the lots of
people expressing dismay and outrage against this proposal that they see
as unwarranted. Please consider that this is still very poor evidence,
and data of poorly ascertained quality. I hope we can hear about data
both of better quality, and from the other side.

Ideally, the first to put forward this convincing data would be the ones
who came forward with this issue in the first place, with the claim
that "master" offends people, and the intent to drive change about it -
so this would be Simon and Don. Simon, Don, can you help here? Strong
elements to back up and ground in reality this obviously controversial
claim could really help to get people on board with this effort; I hope
you don't drop the ball here!