The master branch rename, and avoiding another v1.6.0 git-foo fiasco

The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras]

Hello,

Some of you may remember the fiasco that was the v1.6.0 release, which
obsoleted all the git-foo commands, and caused a huge revolt among
users.

What you may not remember is the suggestion I gave Linus Torvalds to
avoid such issues in the future: [1]

  What other projects do is make very visible when something is
  deprecated, like a big, annoying, unbearable warning. Next time you
  deprecated a command it might be a good idea to add the warning each
  time the command is used, and obsolete it later on.

  Also, if it's a big change like this git- stuff, then do a major
  version bump.

  If you had marked 1.6 as 2.0, and added warnings when you deprecated
  the git-foo stuff then the users would have no excuse. It would have
  been obvious and this huge thread would have been avoided.

https://lore.kernel.org/git/94a0d4530808290712s2044dd03pb93cb4a829dc56b0@mail.gmail.com/

[It's worthwhile to read (or reread) the thread to consider the
arguments back and forth.]

This is precisely what was done for Git 2.0, with the addition of
configurations such as "push.default" that enabled the new behavior,
and if unset, a huge warning was issued.

The deprecation period allowed users to become aware of the upcoming
changes, test them, complain about them, or simply disable the
warning, and continue as they were.

The Git project learned its lesson, and the transition to Git 2.0 was
much smoother than v1.6.

Now with the master branch rename we are treading on dangerous waters again.

Regardless of the reasoning behind (of which I didn't see much
discussion, and I can provide strong arguments against), the move will
affect *all* users. Such huge changes are meant for major
versions--like Git 3.0 (which we are due for).

It is not a question of changing one line of code, it's about updating
hundreds--probably thousands--of instances in various documentations
that assume the name of the branch to be "master". This is what I
argued back in 2008 when I pushed against the sudden move to "git
foo", although apparently too late to be considered. [2]

*If* we are going to rename the master branch, it should be with a
good reason, after discussing it appropriately, in a major release
(i.e. Git 3.0), after a period of deprecation, and a big warning to
invite users to provide feedback about the important upcoming change.
We can hedge these types of changes with a "core.mode=next"
configuration, as I argued back in 2013. [3]

If we don't, we are inviting what happened back in 2008 to happen again.

"Those who cannot remember the past are condemned to repeat it." --
George Santayana

Cheers.

[1] https://lore.kernel.org/git/94a0d4530808290712s2044dd03pb93cb4a829dc56b0@mail.gmail.com/
[2] https://lore.kernel.org/git/94a0d4530808271709s4e96c5a7ie6152b2937f2234b@mail.gmail.com/
[3] https://lore.kernel.org/git/1381561485-20252-1-git-send-email-felipe.contreras@gmail.com/

-- 
Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[brian m. carlson]

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

On 2020-11-13 at 00:04:23, Felipe Contreras wrote:
> *If* we are going to rename the master branch, it should be with a
> good reason, after discussing it appropriately, in a major release
> (i.e. Git 3.0), after a period of deprecation, and a big warning to
> invite users to provide feedback about the important upcoming change.
> We can hedge these types of changes with a "core.mode=next"
> configuration, as I argued back in 2013. [3]

When the original email that proposed this change came up, I did suggest
that this would be suitable for a Git 3.0.  I think such a version
number bump would be valuable, but I know that Git doesn't follow
semantic versioning and I'm happy for Junio to make the call.  Git has
made incompatible changes in the past in non-major versions, so there is
precedent for this, although I agree it has the potential to be
surprising.  Again, I defer to Junio's judgment here.

I should point out that there is an option to test or set this already,
with init.defaultBranch.  I have used this feature for testing in the
past, and I use the feature now to set default branches.  It's also
possible to use the template functionality to set a default branch name
for new repositories and I've tested support for this back to at least
Git 2.0 (but I believe it goes back even farther).  And, of course,
either of these options can be used for developers to choose the branch
name which meets the needs of the project best.

As for consultation with users, there was a discussion about this on the
list a few months back and we did get a lot of input from various
parties.  Some of that feedback was hostile and inappropriate and some
even violated our code of conduct in my view, as is all too common with
potentially controversial topics, and I'm not eager to repeat such a
discussion, since I don't think it's going to result in a productive,
positive outcome.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

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

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras]

On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2020-11-13 at 00:04:23, Felipe Contreras wrote:
> > *If* we are going to rename the master branch, it should be with a
> > good reason, after discussing it appropriately, in a major release
> > (i.e. Git 3.0), after a period of deprecation, and a big warning to
> > invite users to provide feedback about the important upcoming change.
> > We can hedge these types of changes with a "core.mode=next"
> > configuration, as I argued back in 2013. [3]
>
> When the original email that proposed this change came up, I did suggest
> that this would be suitable for a Git 3.0.  I think such a version
> number bump would be valuable, but I know that Git doesn't follow
> semantic versioning and I'm happy for Junio to make the call.  Git has
> made incompatible changes in the past in non-major versions, so there is
> precedent for this, although I agree it has the potential to be
> surprising.  Again, I defer to Junio's judgment here.

I have not been following the Git project for a while, but during the
Git 2.0 development I proposed considerable drastic changes, which
Junio said could not fit into v2.0, but perhaps v3.0, which according
to him: [1]

"Even if we end up having to wait for 3.0, it will happen within two
years max, if not earlier." -- Junio 2014

There are actual good backwards-incompatible changes that a new major
release of Git would benefit from, so if Junio changed his mind about
considering these types of changes, it would be good to know.

I for one haven't noticed a single backwards-incompatible change since v2.0.

> I should point out that there is an option to test or set this already,
> with init.defaultBranch.  I have used this feature for testing in the
> past, and I use the feature now to set default branches.  It's also
> possible to use the template functionality to set a default branch name
> for new repositories and I've tested support for this back to at least
> Git 2.0 (but I believe it goes back even farther).  And, of course,
> either of these options can be used for developers to choose the branch
> name which meets the needs of the project best.

There was also the option to test the future changes in v1.6.0, that's
not the point.

The point is that users **must be warned**--and very annoyingly
so--before obsoleting something.

> As for consultation with users, there was a discussion about this on the
> list a few months back and we did get a lot of input from various
> parties.  Some of that feedback was hostile and inappropriate and some
> even violated our code of conduct in my view, as is all too common with
> potentially controversial topics, and I'm not eager to repeat such a
> discussion, since I don't think it's going to result in a productive,
> positive outcome.

I looked for this kind of discussion, but didn't find it. I didn't
imagine it was as far back as June.

It took a while, but I finally read the whole thread, and I understand
your unwillingness to repeat such a discussion, but unfortunately it
will have to happen again, because the people that participated in
that discussion are but a tiny minority that is not representative of
all Git users. If not now, it will happen in the future. This is
exactly what happened in 2008, when the issue was discussed in at
least three big threads.

Moreover, my point was not discussed in that thread. You mentioned it,
but everyone focused on tangents, such as the state of the culture
war, and the etymology of the word "master".

To try to save your sanity I will attempt to be brief (but probably
not as brief as you would like to).

This is what was discussed:

1. Adding a configuration (init.defaultbranch)
2. Should the name of the master branch be changed?
3. Best alternative name for the master branch
4. Culture war
5. The impact to users

I have a lot to say about 4, 3, and 2, and perhaps I will do so in
another thread, but that's not important, what is important is the
thing that was not discussed: the users.

I like to refer to a panel Linus Torvalds participated in regarding
the importance of users [2]. I consider this an explanation of the
first principles of software: the main purpose of software is that
it's useful to users, and that it continues to be useful as it moves
forward. To quote Torvalds:

"Any time a program breaks the user experience, to me that is the
absolute worst failure that a software project can make." -- Linus
Torvalds

This is the first thing the Git project should be worried about, not
the current state of the culture war, and I didn't see anyone
championing the users, and how this change will negatively impact
their experience, which arguably has been pretty stable throughout the
years (at least since 2008).

That being said, I want to touch on only one point you brought
forward, that is indirectly relevant to the users.

You mentioned the importance of intent [3], and how we can never be
certain of the intent of another person, this is true. However, we
must try to guess what the interlocutor might have meant, otherwise
there is no point in communication. This is realized in Wikipedia's
fundamental principle of always assuming good faith [4], Grice's
philosophical razor: prefer what the speaker meant over what the
sentence they spoke literally meant [5][6].

You cannot stand in a comedy special without realizing what the comic
actually means, and it rarely is what he literally says. If I utter
the phrase "kill me now", you know what I mean, or more importantly;
what I don't mean.

A lot of people today want to ignore this fundamental aspect of human
language, and they do so for political reasons. But it doesn't stop it
from being the case. It's not a coincidence that since 2005 nobody had
any problem with the word "master", it's only in 2020 that the issue
"magically" popped up. And it's no coincidence either what kind of
people are pushing for this change.

This is a solution looking for a problem.

There is a concept called "the silent majority" which applies in
software. Most Git users are not going to participate in culture war
debates in the mailing list. It is usually a tiny vociferous minority
that drives these kinds of discussions (and if it has to be said; I
don't mean any negative connotation, simply stating that they are the
opposite of silent). Even the users that are supposedly the target of
these progressive changes (e.g. black users descendant of slaves) will
probably not care at all about such changes, because they are part of
the silent majority that uses common sense and understands that
nothing ill was intended by the word "master". It is usually white
people that "defend" these "oppressed minorities" without their
consent, or need.

Did we hear the testimony of a single black person that was offended
by the word?

The intellectual Gad Saad wrote about a disorder called Munchausen
syndrome by proxy, and how it explains what many modern activists do:
[7]

"Munchausen Syndrome is where a person feigns illness, or medical
conditions, to garner empathy and sympathy. Munchausen Syndrome by
proxy is when you take someone who is under your care (your biological
child, your pet, your elderly parent) and then harm that person or
entity that’s under your care so that you can then garner the empathy
and sympathy by proxy."

Nobody affected by this change actually asked for this change, it is
being done *preemptively* just in case some actual target user might
find it offensive. The only people actually being offended are
offended *by proxy*.

I recommend the book The Parasitic Mind: How Infectious Ideas Are
Killing Common Sense, which explains this and many more problems of
the current culture war.

I have a lot more to say about this, believe me, and perhaps I will do
so in another thread, but for now the summary is this:

We are going to *actually* harm true users that understand the intent
behind the word "master" hoping we might benefit marginally some
imaginary users.

And if we don't warn them about the upcoming change, before the change
is actually implemented (as we did with push.default), they will
complain. Because unlike the users that are descendants of black
slaves who misinterpret what Git developers meant by the word "master"
and get offended as result--they are *real*, and they are a lot.

Cheers.

[1] https://lore.kernel.org/git/xmqqioq12eif.fsf@gitster.dls.corp.google.com/
[2] https://www.youtube.com/watch?v=kzKzUBLEzwk
[3] https://lore.kernel.org/git/20200614190842.GC6531@camp.crustytoothpaste.net/
[4] https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
[5] https://rationalwiki.org/wiki/Logical_razor#Grice.27s_razor
[6] https://plato.stanford.edu/entries/implicature/
[7] https://thoughteconomics.com/gad-saad/

-- 
Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Theodore Y. Ts'o]

Maybe I'm missing something, but I'm very confused about what is going
to be changed that you are concerned about.  What is it precisely that
going to be happening (or which you think is going to be happening)
which is causing you concern?


Is it changing the default branch name when creating a new repository?
(Which affects only people creating new repositories)

Is it renaming the master branch for the git repo?  (which affects
people who are developing or tracking git via the repository, as
opposed to using a pre-packaged git provided by their Linux
Distributions / OS).

Is it improving the tools so that other projects can more easily
rename their primary development branch from master to main?  (Which
many projects have been doing *already*, without not a lot of Sturm
und Drang as near as I can tell, at least in many/most cases.)

Is it removing places in the git program where "master" is treated
specially (e.g., in how the default text for merge descrtipion is
worded)?

What, specifically, is the "backwards incompatible change" that you
are most worried about?  Because many projects have already been
renaming their primary development branch from master to main
*already*.

						- Ted

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Don Goodman-Wilson]

> Did we hear the testimony of a single black person that was offended
by the word?

> Nobody affected by this change actually asked for this change

Five minutes searching Twitter will reveal a great number of Black git users championing this change.

How is reopening this discussion anything but a distraction?

Don Goodman-Wilson

> On 13 Nov 2020, at 05:27, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> 
> 
> On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>> 
>> On 2020-11-13 at 00:04:23, Felipe Contreras wrote:
>>> *If* we are going to rename the master branch, it should be with a
>>> good reason, after discussing it appropriately, in a major release
>>> (i.e. Git 3.0), after a period of deprecation, and a big warning to
>>> invite users to provide feedback about the important upcoming change.
>>> We can hedge these types of changes with a "core.mode=next"
>>> configuration, as I argued back in 2013. [3]
>> 
>> When the original email that proposed this change came up, I did suggest
>> that this would be suitable for a Git 3.0.  I think such a version
>> number bump would be valuable, but I know that Git doesn't follow
>> semantic versioning and I'm happy for Junio to make the call.  Git has
>> made incompatible changes in the past in non-major versions, so there is
>> precedent for this, although I agree it has the potential to be
>> surprising.  Again, I defer to Junio's judgment here.
> 
> I have not been following the Git project for a while, but during the
> Git 2.0 development I proposed considerable drastic changes, which
> Junio said could not fit into v2.0, but perhaps v3.0, which according
> to him: [1]
> 
> "Even if we end up having to wait for 3.0, it will happen within two
> years max, if not earlier." -- Junio 2014
> 
> There are actual good backwards-incompatible changes that a new major
> release of Git would benefit from, so if Junio changed his mind about
> considering these types of changes, it would be good to know.
> 
> I for one haven't noticed a single backwards-incompatible change since v2.0.
> 
>> I should point out that there is an option to test or set this already,
>> with init.defaultBranch.  I have used this feature for testing in the
>> past, and I use the feature now to set default branches.  It's also
>> possible to use the template functionality to set a default branch name
>> for new repositories and I've tested support for this back to at least
>> Git 2.0 (but I believe it goes back even farther).  And, of course,
>> either of these options can be used for developers to choose the branch
>> name which meets the needs of the project best.
> 
> There was also the option to test the future changes in v1.6.0, that's
> not the point.
> 
> The point is that users **must be warned**--and very annoyingly
> so--before obsoleting something.
> 
>> As for consultation with users, there was a discussion about this on the
>> list a few months back and we did get a lot of input from various
>> parties.  Some of that feedback was hostile and inappropriate and some
>> even violated our code of conduct in my view, as is all too common with
>> potentially controversial topics, and I'm not eager to repeat such a
>> discussion, since I don't think it's going to result in a productive,
>> positive outcome.
> 
> I looked for this kind of discussion, but didn't find it. I didn't
> imagine it was as far back as June.
> 
> It took a while, but I finally read the whole thread, and I understand
> your unwillingness to repeat such a discussion, but unfortunately it
> will have to happen again, because the people that participated in
> that discussion are but a tiny minority that is not representative of
> all Git users. If not now, it will happen in the future. This is
> exactly what happened in 2008, when the issue was discussed in at
> least three big threads.
> 
> Moreover, my point was not discussed in that thread. You mentioned it,
> but everyone focused on tangents, such as the state of the culture
> war, and the etymology of the word "master".
> 
> To try to save your sanity I will attempt to be brief (but probably
> not as brief as you would like to).
> 
> This is what was discussed:
> 
> 1. Adding a configuration (init.defaultbranch)
> 2. Should the name of the master branch be changed?
> 3. Best alternative name for the master branch
> 4. Culture war
> 5. The impact to users
> 
> I have a lot to say about 4, 3, and 2, and perhaps I will do so in
> another thread, but that's not important, what is important is the
> thing that was not discussed: the users.
> 
> I like to refer to a panel Linus Torvalds participated in regarding
> the importance of users [2]. I consider this an explanation of the
> first principles of software: the main purpose of software is that
> it's useful to users, and that it continues to be useful as it moves
> forward. To quote Torvalds:
> 
> "Any time a program breaks the user experience, to me that is the
> absolute worst failure that a software project can make." -- Linus
> Torvalds
> 
> This is the first thing the Git project should be worried about, not
> the current state of the culture war, and I didn't see anyone
> championing the users, and how this change will negatively impact
> their experience, which arguably has been pretty stable throughout the
> years (at least since 2008).
> 
> That being said, I want to touch on only one point you brought
> forward, that is indirectly relevant to the users.
> 
> You mentioned the importance of intent [3], and how we can never be
> certain of the intent of another person, this is true. However, we
> must try to guess what the interlocutor might have meant, otherwise
> there is no point in communication. This is realized in Wikipedia's
> fundamental principle of always assuming good faith [4], Grice's
> philosophical razor: prefer what the speaker meant over what the
> sentence they spoke literally meant [5][6].
> 
> You cannot stand in a comedy special without realizing what the comic
> actually means, and it rarely is what he literally says. If I utter
> the phrase "kill me now", you know what I mean, or more importantly;
> what I don't mean.
> 
> A lot of people today want to ignore this fundamental aspect of human
> language, and they do so for political reasons. But it doesn't stop it
> from being the case. It's not a coincidence that since 2005 nobody had
> any problem with the word "master", it's only in 2020 that the issue
> "magically" popped up. And it's no coincidence either what kind of
> people are pushing for this change.
> 
> This is a solution looking for a problem.
> 
> There is a concept called "the silent majority" which applies in
> software. Most Git users are not going to participate in culture war
> debates in the mailing list. It is usually a tiny vociferous minority
> that drives these kinds of discussions (and if it has to be said; I
> don't mean any negative connotation, simply stating that they are the
> opposite of silent). Even the users that are supposedly the target of
> these progressive changes (e.g. black users descendant of slaves) will
> probably not care at all about such changes, because they are part of
> the silent majority that uses common sense and understands that
> nothing ill was intended by the word "master". It is usually white
> people that "defend" these "oppressed minorities" without their
> consent, or need.
> 
> Did we hear the testimony of a single black person that was offended
> by the word?
> 
> The intellectual Gad Saad wrote about a disorder called Munchausen
> syndrome by proxy, and how it explains what many modern activists do:
> [7]
> 
> "Munchausen Syndrome is where a person feigns illness, or medical
> conditions, to garner empathy and sympathy. Munchausen Syndrome by
> proxy is when you take someone who is under your care (your biological
> child, your pet, your elderly parent) and then harm that person or
> entity that’s under your care so that you can then garner the empathy
> and sympathy by proxy."
> 
> Nobody affected by this change actually asked for this change, it is
> being done *preemptively* just in case some actual target user might
> find it offensive. The only people actually being offended are
> offended *by proxy*.
> 
> I recommend the book The Parasitic Mind: How Infectious Ideas Are
> Killing Common Sense, which explains this and many more problems of
> the current culture war.
> 
> I have a lot more to say about this, believe me, and perhaps I will do
> so in another thread, but for now the summary is this:
> 
> We are going to *actually* harm true users that understand the intent
> behind the word "master" hoping we might benefit marginally some
> imaginary users.
> 
> And if we don't warn them about the upcoming change, before the change
> is actually implemented (as we did with push.default), they will
> complain. Because unlike the users that are descendants of black
> slaves who misinterpret what Git developers meant by the word "master"
> and get offended as result--they are *real*, and they are a lot.
> 
> Cheers.
> 
> [1] https://lore.kernel.org/git/xmqqioq12eif.fsf@gitster.dls.corp.google.com/
> [2] https://www.youtube.com/watch?v=kzKzUBLEzwk
> [3] https://lore.kernel.org/git/20200614190842.GC6531@camp.crustytoothpaste.net/
> [4] https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
> [5] https://rationalwiki.org/wiki/Logical_razor#Grice.27s_razor
> [6] https://plato.stanford.edu/entries/implicature/
> [7] https://thoughteconomics.com/gad-saad/
> 
> --
> Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras]

On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:

> Is it changing the default branch name when creating a new repository?
> (Which affects only people creating new repositories)

You may choose to downplay the experience of certain part of the
user-base, because in your experience creating new repositories
doesn't happen often, but that doesn't mean these users don't exist.

Yes, this is the part I'm concerned about.

At this very moment there's people in universities trying to learn Git
and creating repositories, so are people training in companies.
There's a whole industry dedicated to teaching Git, and they rely on
creating repositories.

A simple "git grep master" on the documentation of git.git (without
the release notes) shows at least 800 instances.

This is precisely the part that was neglected in the v1.6.0 release
that I undertook: nobody bothered to change the documentation that was
using git-foo commands.

I find it curious that this is the criticism you choose to give on a
change that is supposed to be making Git more inclusive towards people
with different experiences (potentially non-existent); making light of
the experiences of very real people which we know exist.

Shouldn't we be inclusive towards these very real users as well?

Since this is 2020, and just to be crystal clear: I intend no offense,
I just truly find this argument curious.

Cheers.

-- 
Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras]

On Fri, Nov 13, 2020 at 12:02 AM D.E. Goodman-Wilson
<don@goodman-wilson.com> wrote:
> > Did we hear the testimony of a single black person that was offended
> by the word?
>
> > Nobody affected by this change actually asked for this change
>
> Five minutes searching Twitter will reveal a great number of Black git users championing this change.

This is anecdotal evidence.

We all live in our own digital bubble. Every person's Twitter feed is
different, and Google search results depend on where you live, and
your past searches.

You may find "a great number" of users that match that criteria, what
I find is only people criticizing the move, and after five minutes I
haven't found a single black person actually offended by the current
name.

> How is reopening this discussion anything but a distraction?

This discussion never happened.

Everyone in the June thread argued about the different names of the
potential branch, and the culture war implications. Virtually *nobody*
argued about the manner of implementation: deprecation period, clear
warnings, Git 3.0 consideration.

I'd argue *that* was the distraction.

In 2008 people started multiple threads *after* the sudden change to
git-foo without warning happened.

If we do the same, this discussion will happen again. I'm just the
canary in the coal mine giving you a heads up.

Choosing to ignore the very real danger doesn't make the very real
danger go away, you are just delaying it and making it potentially
bigger. You choose to ignore the canary at your own peril. This is
precisely what happened in 2008.

Cheers.

-- 
Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Philippe Blain]

Hi Felipe, 

> Le 13 nov. 2020 à 01:47, Felipe Contreras <felipe.contreras@gmail.com> a écrit :
> 
> On Fri, Nov 13, 2020 at 12:02 AM D.E. Goodman-Wilson
> <don@goodman-wilson.com> wrote:
>>> Did we hear the testimony of a single black person that was offended
>> by the word?
>> 
>>> Nobody affected by this change actually asked for this change
>> 
>> Five minutes searching Twitter will reveal a great number of Black git users championing this change.
> 
> This is anecdotal evidence.
> 
> We all live in our own digital bubble. Every person's Twitter feed is
> different, and Google search results depend on where you live, and
> your past searches.
> 
> You may find "a great number" of users that match that criteria, what
> I find is only people criticizing the move, and after five minutes I
> haven't found a single black person actually offended by the current
> name.
> 
>> How is reopening this discussion anything but a distraction?
> 
> This discussion never happened.
> 
> Everyone in the June thread argued about the different names of the
> potential branch, and the culture war implications. Virtually *nobody*
> argued about the manner of implementation: deprecation period, clear
> warnings, Git 3.0 consideration.

I couldn't agree more. We really need to be warning users several versions in advance,
and I mean months or even years. I don't wan't to come up with a number, but I would
guess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion
on that topic ever took place.

Brian mentioned that some people voicing their concern on the list did not abide by the code of conduct. 
There was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the
discussion reached the mailing list, of which a lot was also considered to not abide by that project's
code of conduct. While I agree that discussion should be done with respect, and some people that 
are driven to react to such important changes might not be aware of any code of conduct they should 
follow, because they don't participate in the "day-to-day" life of the project, just the fact that they even
care enough to voice their disagreement should be a big red flag in terms of how this change should be done,
in my opinion.

I had avoided commenting on this whole subject, but the main point you are bringing, 
that such a change, if done, should be made with great care to our user base and a lot 
more warning, is a very important one. 

Thanks for bringing it up.

Philippe.

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Theodore Y. Ts'o]

On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras wrote:
> On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> 
> > Is it changing the default branch name when creating a new repository?
> > (Which affects only people creating new repositories)
> 
> You may choose to downplay the experience of certain part of the
> user-base, because in your experience creating new repositories
> doesn't happen often, but that doesn't mean these users don't exist.

OK, fine.  That wasn't clear in your earlier messages.  So this is
*not* like 2008, where we are breaking workflows or finger macros of
*existing* git users.

Instead, we might be causing a certain amount of confusion with
respect to *new* users, especially if some portion of them are using
an older version of git, where the default initial branch name is
"master", or a newer version of git, where the default initial branch
name is "main".

It's important we be specific about the concern, as opposed to using
abstract notions of "backwards compatibility".  Because I'll note that
even if we were to release a git 3.0, it's not going to fix the
potential confusion where some students / new users trying to follow a
tutorial are using git 2.x, and some are using git 3.x.

We could delay making the change for years, but that isn't going to
guarantee that all of the various tutorials on the 'net will be
changed, and experience from long deprecation periods (exhibit 1:
Pythonx 2.x vs Python 3) is that people will drag there feet and put
off doing the work to migrate for years and years and years.

So I think it's worth making explicit exact what the nature of the
breakage is: specifically, some confusion for new users following
tutorials that haven't been updated, and to balance that off against
the costs of delaying the change for years and years and years.  And
that's because individual projects and individual git repositories are
making that change *already*.  So changing what the default "out of
the box" might be in some ways will make it worse for new users who
follow the some random git tutorial or traning on the web and then
then have to interact with some open source community which has
already changed their primary development branch to be "main".

If we know that's the concern, then we can improve the messaging and
documentation, and I appreciate that you have done some work along
those lines already.  So let's see how we can address the problem
constructively; maybe that means making the git default trailing edge
as opposed to helping to lead the change.   Maybe not.

   	      	      	      	  	    - Ted

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras]

On Fri, Nov 13, 2020 at 8:58 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras wrote:
> > On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> >
> > > Is it changing the default branch name when creating a new repository?
> > > (Which affects only people creating new repositories)
> >
> > You may choose to downplay the experience of certain part of the
> > user-base, because in your experience creating new repositories
> > doesn't happen often, but that doesn't mean these users don't exist.
>
> OK, fine.  That wasn't clear in your earlier messages.  So this is
> *not* like 2008, where we are breaking workflows or finger macros of
> *existing* git users.

In some ways it's not as bad, but in others it's worse.

I suspect the political nature of the change is not going to be well
received, especially if it's snuck on them.

> Instead, we might be causing a certain amount of confusion with
> respect to *new* users, especially if some portion of them are using
> an older version of git, where the default initial branch name is
> "master", or a newer version of git, where the default initial branch
> name is "main".

It's not just new users. There may be other kinds of users accustomed
to creating repositories. Not all users follow the same kind of
workflows, some may not even use Git for software development.

I don't think we can claim with much certainty how *everyone* uses Git.

> It's important we be specific about the concern, as opposed to using
> abstract notions of "backwards compatibility".  Because I'll note that
> even if we were to release a git 3.0, it's not going to fix the
> potential confusion where some students / new users trying to follow a
> tutorial are using git 2.x, and some are using git 3.x.

It's not going to fix them, but it would ameliorate them.

Some people today do know what changed in Bash 4.0, not so much what
changed from 3.1 to 3.2.

This is what major versions are for.

> We could delay making the change for years, but that isn't going to
> guarantee that all of the various tutorials on the 'net will be
> changed, and experience from long deprecation periods (exhibit 1:
> Pythonx 2.x vs Python 3) is that people will drag there feet and put
> off doing the work to migrate for years and years and years.

This is a false equivalence.

Yes, the migration to Python 3 was a problem, the lesson here is:
don't do what Python developers did. Ruby took a completely different
approach, and the move to Ruby 1.x to Ruby 2.0 was basically painless.

The Git project already had one basically painless major version bump,
and in my view it was generally well received. If anything it should
have changed *more* things.

Not all major version bumps are the same, and the Git project can
learn to do them the right way.

> So I think it's worth making explicit exact what the nature of the
> breakage is: specifically, some confusion for new users following
> tutorials that haven't been updated, and to balance that off against
> the costs of delaying the change for years and years and years.  And
> that's because individual projects and individual git repositories are
> making that change *already*.  So changing what the default "out of
> the box" might be in some ways will make it worse for new users who
> follow the some random git tutorial or traning on the web and then
> then have to interact with some open source community which has
> already changed their primary development branch to be "main".

This is once again a false equivalence.

What other projects did is the equivalent of changing the master brain
in git.git to something else. That's up to Junio and I don't
particularly care one way or another (although I would prefer if he
didn't). That would affect a relatively small number of people: Git
developers.

Changing the default of the tool is an entirely different thing that
will affect thousands of people. Apples and oranges.

Then you say if we delay it would be for "years and years and years".
Who said so? Why can't it be one year? Or six months? If it doesn't
happen tomorrow it will have to happen in 2030? No.

And then you mention other projects. Well, what other projects do is
their prerogative. Nobody forced them to make a premature decision,
and if their users suffer as a result, that's on them.

The Git project should not be held hostage by the decisions of other
projects. If it takes a couple of months, or even a year, for a change
to be done right without breaking user expectations, so be it.

> If we know that's the concern, then we can improve the messaging and
> documentation, and I appreciate that you have done some work along
> those lines already.  So let's see how we can address the problem
> constructively; maybe that means making the git default trailing edge
> as opposed to helping to lead the change.   Maybe not.

I think you misunderstood. I did the documentation work in 2008, for
the git-foo change, *after* the change was already rolled out, the
users complained, and I noticed the documentation was not updated.

I have not done anything for the master rename, which I believe is a
huge mistake, and has not been discussed properly yet.

That is a separate subject, here I'm just talking about the impact of
the patch that was just sent.

Moreover, none of what you have argued so far has any bearing on my
point about enabling warnings and a deprecation period.

Even if we don't wait for Git 3.0, a warning should be shown at least
a couple of months before the actual switch happens.

To sneak up an entirely political change like this without warning is
disrespecting the user-base, it's what caused the *huge* complaints in
2008, and it's just not cool.

Cheers.

-- 
Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras]

On Fri, Nov 13, 2020 at 7:53 AM Philippe Blain
<levraiphilippeblain@gmail.com> wrote:

> > This discussion never happened.
> >
> > Everyone in the June thread argued about the different names of the
> > potential branch, and the culture war implications. Virtually *nobody*
> > argued about the manner of implementation: deprecation period, clear
> > warnings, Git 3.0 consideration.
>
> I couldn't agree more. We really need to be warning users several versions in advance,
> and I mean months or even years. I don't wan't to come up with a number, but I would
> guess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion
> on that topic ever took place.

More like 99.9%.

> Brian mentioned that some people voicing their concern on the list did not abide by the code of conduct.
> There was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the
> discussion reached the mailing list, of which a lot was also considered to not abide by that project's
> code of conduct. While I agree that discussion should be done with respect, and some people that
> are driven to react to such important changes might not be aware of any code of conduct they should
> follow, because they don't participate in the "day-to-day" life of the project, just the fact that they even
> care enough to voice their disagreement should be a big red flag in terms of how this change should be done,
> in my opinion.

Yes, the abrasive tone of those users did not help, but neither does
tone policing. At the end of the day they did some valid arguments,
and it will be the users that suffer because the project decided to
focus on the tone, rather than the argument.

> I had avoided commenting on this whole subject, but the main point you are bringing,
> that such a change, if done, should be made with great care to our user base and a lot
> more warning, is a very important one.

Indeed. I am debating whether or not I should bring up the arguments
nobody brought up in that big discussion, because in 2020 the concept
of freedom of speech is lost, and merely stating facts can get you
banned from a community, or worse. But the facts remain true.

For now I think this is the imminent issue, and a warning must be
issued so that users know what is coming. I suspect when they realize
what's coming, they will preemptively complain in the mailing list.

We'll see. But sneaking this change is *definitely* going to upset
many users, making the problem worse.

Cheers.

-- 
Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Michal Suchánek]

On Fri, Nov 13, 2020 at 09:58:02AM -0500, Theodore Y. Ts'o wrote:
> On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras wrote:
> > On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> > 
> > > Is it changing the default branch name when creating a new repository?
> > > (Which affects only people creating new repositories)
> > 
> > You may choose to downplay the experience of certain part of the
> > user-base, because in your experience creating new repositories
> > doesn't happen often, but that doesn't mean these users don't exist.
> 
> OK, fine.  That wasn't clear in your earlier messages.  So this is
> *not* like 2008, where we are breaking workflows or finger macros of
> *existing* git users.
> 
> Instead, we might be causing a certain amount of confusion with
> respect to *new* users, especially if some portion of them are using
> an older version of git, where the default initial branch name is
> "master", or a newer version of git, where the default initial branch
> name is "main".
> 
> It's important we be specific about the concern, as opposed to using
> abstract notions of "backwards compatibility".  Because I'll note that
> even if we were to release a git 3.0, it's not going to fix the
> potential confusion where some students / new users trying to follow a
> tutorial are using git 2.x, and some are using git 3.x.
> 
> We could delay making the change for years, but that isn't going to
> guarantee that all of the various tutorials on the 'net will be
> changed, and experience from long deprecation periods (exhibit 1:
> Pythonx 2.x vs Python 3) is that people will drag there feet and put
> off doing the work to migrate for years and years and years.

But we could, for example, provide a way to specify the default branch
when creating the repository, and rewrite the tutorials to advise users
to specify a branch name, at least the ones provided by git project
itself. Then what the default is does not matter.

Thanks

Michal

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Lukasz Niemier]

> OK, fine.  That wasn't clear in your earlier messages.  So this is
> *not* like 2008, where we are breaking workflows or finger macros of
> *existing* git users.
> 
> Instead, we might be causing a certain amount of confusion with
> respect to *new* users, especially if some portion of them are using
> an older version of git, where the default initial branch name is
> "master", or a newer version of git, where the default initial branch
> name is "main".

I am pretty much **existing** Git user where I am maintaining few repos
yet I am constantly creating new ones for another projects of mine. Such
abrupt change in the default branch name, without any warning, would be
very confusing for me. Not every user is working on a single Git repo
for their whole life.

I feel that our view on who is **new** or **existing** user differs.

--

Łukasz Niemier
lukasz.niemier@kobil.com

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Theodore Y. Ts'o]

On Sat, Nov 14, 2020 at 02:19:59PM +0000, Lukasz Niemier wrote:
> > OK, fine.  That wasn't clear in your earlier messages.  So this is
> > *not* like 2008, where we are breaking workflows or finger macros of
> > *existing* git users.
> > 
> > Instead, we might be causing a certain amount of confusion with
> > respect to *new* users, especially if some portion of them are using
> > an older version of git, where the default initial branch name is
> > "master", or a newer version of git, where the default initial branch
> > name is "main".
> 
> I am pretty much **existing** Git user where I am maintaining few repos
> yet I am constantly creating new ones for another projects of mine. Such
> abrupt change in the default branch name, without any warning, would be
> very confusing for me. Not every user is working on a single Git repo
> for their whole life.

So we need to make sure existing users know that they can add:

[init]
    defaultBranch = master

to their ~/.gitconfig if they want the legacy behavior.  This could be
done by, in addition to mentioning it in the release notes, or by
adding a comment printed out when "git init" is run and there is not
init.defaultBranch defined in ~/.gitconfig.

We do something similar if merge.ff is not in ~/.gitconfig, and people
run "git merge" without --no-ff or --ff-only specified on the command
line.   So there is precedence for this sort of thing.

This *really* is not hard; which is why I am starting to suspect
people are really kvetching because their objections are really more
about the woke/anti-woke aspect of the "master" -> "main" migration
--- and they are using *think* the children^H^H^H^H^H^H^H users as a
rhetorical device.

						- Ted

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras]

On Sat, Nov 14, 2020 at 9:47 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Sat, Nov 14, 2020 at 02:19:59PM +0000, Lukasz Niemier wrote:

> > I am pretty much **existing** Git user where I am maintaining few repos
> > yet I am constantly creating new ones for another projects of mine. Such
> > abrupt change in the default branch name, without any warning, would be
> > very confusing for me. Not every user is working on a single Git repo
> > for their whole life.
>
> So we need to make sure existing users know that they can add:
>
> [init]
>     defaultBranch = master
>
> to their ~/.gitconfig if they want the legacy behavior.  This could be
> done by, in addition to mentioning it in the release notes, or by
> adding a comment printed out when "git init" is run and there is not
> init.defaultBranch defined in ~/.gitconfig.

Which is precisely my suggestion: add a warning.

> We do something similar if merge.ff is not in ~/.gitconfig, and people
> run "git merge" without --no-ff or --ff-only specified on the command
> line.   So there is precedence for this sort of thing.

And we did precisely the same thing with push.default.

> This *really* is not hard; which is why I am starting to suspect
> people are really kvetching because their objections are really more
> about the woke/anti-woke aspect of the "master" -> "main" migration
> --- and they are using *think* the children^H^H^H^H^H^H^H users as a
> rhetorical device.

Exactly.

There's literally no other reason to change the default branch name
(other than woke reasons), and the people against adding such a
warning would be doing so purely due to their personal agenda, because
they are in a hurry to get the change in, regardless of the
implications towards users.

Putting personal agendas aside... we need to add a warning so that
users get notified of the impending change, and let the chips fall
where they may.

Cheers.

-- 
Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Brandon Casey]

On Sat, Nov 14, 2020 at 8:23 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:

> This *really* is not hard; which is why I am starting to suspect
> people are really kvetching because their objections are really more
> about the woke/anti-woke aspect of the "master" -> "main" migration
> --- and they are using *think* the children^H^H^H^H^H^H^H users as a
> rhetorical device.

So we're changing the default branch name from "master" to "main"?

For what purpose?  What problem are we trying to solve?

Is the word "master" now going to become a taboo word that we're all
afraid to say?

Isn't this all a little silly? What's wrong with the term "master"?
It's a well understood and commonly used term that denotes
"authority", i.e. the master branch is the authoritative branch.
People sleep in master bedrooms. Universities have headmasters and
award master's degrees. Skilled people become master craftsmen and
give master classes (e.g. master plumber, master diver). Recording
artists master a track. Skilled chess players become chess masters
etc.

-Brandon

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Peter Hadlaw]

Reposting a bit from a side thread, so excuse me. Felt that this is
more of a relevant place to leave these thoughts.

***
If some people or teams would prefer _their_ default branches to be
anything other than `master`, I'm all for giving them the tools to
live out their dreams. That's what `git config` and the new
`defaultBranch` flag are for. There is no need to force these desires
onto _all_ users.
***

It's worth noting that the word "slave" comes from the en_slav_ement
of Slavs (the Slavic people of Eastern Europe). Check "Slav Twitter"
if you must, you'll find nothing but a chuckle at this situation.

I encourage everyone to really think about the changes you are making.

It was just reported to me that a professional friend of mine had
confusion as to why, after initializing a new repository, they
couldn't navigate to the `master` branch of their repository.

I understand this is back-of-the-napkin type math but stay with me for
one moment. I also understand GitHub is not all of git users, but I
just pulled the number to help me out here.

If GitHub has 40 million users but let's say half of them aren't
active, so now we are at 20 million.

(Replace this number with how many actual users of git are out there.)

Let's even say half of them are on board and aware of this "harmless"
change to a more "sensitive" doublespeak representation of the
"master" copy/branch of the repo. That leaves us with 10 million users
of git that are either unaware or are not on board. Let's say it takes
3 minutes for a user to search on the web why exactly they can't
navigate to their "master" branch. That's 30 million minutes wasted,
or about 57 man-YEARs of time wasted.... for what? Oh but you'll ask
them what their default is? Do the same math... better yet realize
this is just a power exercise of one very tiny group over another.

When do we put our foot down and say enough is enough, and not
everything is offensive?

Again, please reconsider making this change towards
doublespeak/Newspeak and consider the ramifications of how much actual
human life & time will be wasted. Ignoring adding on the new
reputation of the git project to kowtow to "current year" politics.

Besides just the annoyance to users in their day to day, yes there is
mention of "just update the tutorials!" but what a way to dishonor the
millions of hours people have put into welcoming other individuals to
the git community. There is no reason to outdate their tutorials and
documentation so prematurely (and yet again exercise power over them
by making them update their content for no real reason).

--
Peter

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Konstantin Ryabitsev]

On Wed, Nov 18, 2020 at 05:02:59PM -0800, Brandon Casey wrote:
> > This *really* is not hard; which is why I am starting to suspect
> > people are really kvetching because their objections are really more
> > about the woke/anti-woke aspect of the "master" -> "main" migration
> > --- and they are using *think* the children^H^H^H^H^H^H^H users as a
> > rhetorical device.
> 
> So we're changing the default branch name from "master" to "main"?

To my knowledge, there are no concrete plans to change anything at this 
time. All recent work was to remove any special-case treatment of 
"master" as the default branch name, so people are free to use any 
configuration they like.

> For what purpose?  What problem are we trying to solve?

People want to be able to use arbitrary branch names.

> Is the word "master" now going to become a taboo word that we're all
> afraid to say?

No, everyone is welcome to use it if they like. It has perfectly 
legitimate usage cases -- for example, some of the staunchest opponents 
of this terminology continue to list their "Master of Arts" degree on 
LinkedIn.

> Isn't this all a little silly? What's wrong with the term "master"?

It is misleading in the context of git, because it implies that a branch 
carrying that name is in some way special compared to other branches 
(e.g. like "trunk" in the SVN world). In reality, the "master" branch is 
just a branch like all others (and can be missing entirely or have junk 
in it), so it really shouldn't be called "master".

> It's a well understood and commonly used term that denotes
> "authority", i.e. the master branch is the authoritative branch.
> People sleep in master bedrooms. Universities have headmasters and
> award master's degrees. Skilled people become master craftsmen and
> give master classes (e.g. master plumber, master diver). Recording
> artists master a track. Skilled chess players become chess masters
> etc.

Exactly, thank you for illustrating my point. In all of the above 
situations the word "master" is used to indicate some kind of 
distinction. If all you have is a single bedroom, it would be kinda 
obnoxious to refer to it as "the master bedroom," eh? :)

-K

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Junio C Hamano]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

>> So we're changing the default branch name from "master" to "main"?
>
> To my knowledge, there are no concrete plans to change anything at this 
> time. All recent work was to remove any special-case treatment of 
> "master" as the default branch name, so people are free to use any 
> configuration they like.

That is a fair description of one state which is a bit stale.

All recent work has been to make sure our tests will not lose test
coverage when we decide to change the fallback default value for
init.defaultBranch to a value other than 'master'.  In other words,
we have been talking about changing (or not changing).

The question most useful to ask at this point are to what name
(fixed? computed?) and what the transition plan would look like.

>> For what purpose?  What problem are we trying to solve?
>
> People want to be able to use arbitrary branch names.

What you gave was the purpose of init.defaultBranch we've introduced
in the last release, but that does not answer the question you are
answering.

The discussion thread you posted to, however, is already talking
about changing (or not changing) the fallback default value for that
variable, i.e. what name does the initial branch get upon "git init"
for end-users who do not indicate any preference.

Some understand well that the primary reason to switch to 'main' is
to help people who will need to interact with projects and hosting
providers that have done the same switch already [*1*].  Some do not
buy that reason well and ask "why?".  You need to give an answer to
the latter.

>> Is the word "master" now going to become a taboo word that we're all
>> afraid to say?
>
> No, everyone is welcome to use it if they like. It has perfectly 
> legitimate usage cases -- for example, some of the staunchest opponents 
> of this terminology continue to list their "Master of Arts" degree on 
> LinkedIn.

Correct.

>> Isn't this all a little silly? What's wrong with the term "master"?
>
> It is misleading in the context of git, because it implies that a branch 
> carrying that name is in some way special compared to other branches 
> (e.g. like "trunk" in the SVN world). In reality, the "master" branch is 
> just a branch like all others (and can be missing entirely or have junk 
> in it), so it really shouldn't be called "master".

I find the above answer even more confusing, in the context of major
projects and hosting sites all moving to 'main'.  If 'master' is
misleading for all the reasons stated in the above paragraph, 'main'
would equally be misleading.  In other words, "It is just a branch
like all others, so it really shouldn't be 'master'" leads to "it
shouldn't be 'main' or 'primary', either".

I personally am fond of this line of "let's not treat one single
thing any special among others" thinking, but I think the way people
use the initially created branch tends to make it special at the end
of the day.

While the project is still in its infancy, you may use that as the
only branch until the tree of the project starts to take its shape,
perhaps with subdirectories dedicated to sources, documentation, and
overall build procedure, etc.  Then you may start to fork different
branches off of it to work on topics that last more than one
commit's worth of time.  At that point, it is likely you'd use the
initially created branch as the primary integration branch, until
you start to need the second and third integration branches.  Like
it or not, the primary integration branch would inevitably end up
being something more special than others, and it is likely that
using the initially created branch for that purpose would be the
most convenient.  There however may exist two or more equally
significant branches, not just one special one, though, but it is
reasonable to have at least one special one.

And for this reason, it does not make much sense to change the
fallback default to "unnamed"---that would force everybody to
immediately rename it (or set init.defaultBranch).


[Footnote]

*1* We expect many projects end users would interact with to be
    using 'main' as the branch of primary interest, and cloning from
    such a project would give you 'main' (i.e. "git clone" finds
    what name the other side users, and uses the same name locally).
    If a new user is starting their Git experience from scratch in
    such a world, it would be more helpful if their "git init"
    placed them on the 'main' branch, and their hello world project
    built on that single branch is pushed to the 'main' branch in
    their publishing repository at hosting sites'.  In such a world,
    tutorial books will all be written with 'main' as the initial
    branch name, too, even though good ones would mention that
    historically 'master' has been used and the readers would see
    projects with history longer than readers' Git lifetime may
    still use 'master' as the primary branch.

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Brandon Casey]

On Thu, Nov 19, 2020 at 5:37 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Wed, Nov 18, 2020 at 05:02:59PM -0800, Brandon Casey wrote:
> > > This *really* is not hard; which is why I am starting to suspect
> > > people are really kvetching because their objections are really more
> > > about the woke/anti-woke aspect of the "master" -> "main" migration
> > > --- and they are using *think* the children^H^H^H^H^H^H^H users as a
> > > rhetorical device.
> >
> > So we're changing the default branch name from "master" to "main"?
>
> To my knowledge, there are no concrete plans to change anything at this
> time. All recent work was to remove any special-case treatment of
> "master" as the default branch name, so people are free to use any
> configuration they like.

Glad to hear that. That doesn't seem to be the perspective that others
have in this discussion thread though, especially since Theodore Ts'o
referred to "...the "master" -> "main" migration" in his comment that
I quoted above.

Thanks for trying to respond to my questions, but I think your
responses are mostly misdirected towards an issue that I was not
referring to. That being the configurability of the default branch
name, which I doubt anyone has a problem with, as opposed to changing
the default branch name for all newly created repositories and
possibly for the git repo itself for some supposed offensiveness of
the word "master". That is what I consider silly.

For example, when I asked "So we're changing the default branch name
from "master" to "main"?" and then followed that up with "For what
purpose?", the latter question was asking "For what purpose are we
changing the default branch name from "master" to "main"?", and then
"What problem are we trying to solve by changing the default branch
name from "master" to "main"?" etc.

-Brandon

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras]

On Thu, Nov 19, 2020 at 3:25 PM Junio C Hamano <gitster@pobox.com> wrote:

> Some understand well that the primary reason to switch to 'main' is
> to help people who will need to interact with projects and hosting
> providers that have done the same switch already [*1*].  Some do not
> buy that reason well and ask "why?".  You need to give an answer to
> the latter.

How exactly does this help people interacting with GitHub?

The main instructions in GitHub while creating a new repository are:

  echo "# test" >> README.md
  git init
  git add README.md
  git commit -m "first commit"
  git branch -M main
  git remote add origin $url
  git push -u origin main

Changing the default to "main" would modify the instructions to:

  echo "# test" >> README.md
  git init
  git add README.md
  git commit -m "first commit"
  git remote add origin $url
  git push -u origin main

One line. That's it.

Moreover, they can already get rid of that line, all they have to do
is "git init -b main" instead of "git init".

Why haven't they updated the instructions?

Ahh, that's right... it's because the instructions are meant to work
on older versions of git as well.

Therefore, even if the default was changed in Git 2.30, they will not
change the instructions.

It's very likely that even if Git changes the default in 2020, GitHub
will not change the instructions by 2022, possibly 2024 (if the world
still stands).

So how exactly will this change help GitHub and other hosting providers?

The anti-master camp came here *demanding* a name change, and in the
process of discussing many claims were simply taken for granted, even
though no prima facie was offered.

But no, the claim that this change will "help people who will need to
interact with projects and hosting providers that have done the same
switch already" has not met its burden of proof.

In fact, no attempt has even been made to explain *how* it would help.

Cheers.

-- 
Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras]

On Thu, Nov 19, 2020 at 3:29 PM Brandon Casey <drafnel@gmail.com> wrote:
> On Thu, Nov 19, 2020 at 5:37 AM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:

> > To my knowledge, there are no concrete plans to change anything at this
> > time. All recent work was to remove any special-case treatment of
> > "master" as the default branch name, so people are free to use any
> > configuration they like.
>
> Glad to hear that. That doesn't seem to be the perspective that others
> have in this discussion thread though, especially since Theodore Ts'o
> referred to "...the "master" -> "main" migration" in his comment that
> I quoted above.

Let me try to clarify to you.

At this precise moment the name of the branch is "master", and will
continue to be until a concrete plan to change it is put forward.

However, the momentum is there to change the default name. So, if the
camp in favor of the change keeps pushing forward, finishes all the
necessary work, and puts a plan in place--which will probably include
a precautionary warning--the name will likely be eventually changed.
It's only a matter of when.

Since there's many agendas: a) get the name changed as soon as
possible, b) change the name, but do it properly and take as long as
is indeed, c) change the name, but not necessarily to "main", and d)
do not change the name; what you are seeing is probably a clash of
many agendas and no clarity from the project.

Moreover, once the plan is set in motion, and many users are notified
of things upcoming change, I suspect there will be a backlash, and the
"decision" might be reconsidered.

So, even though things are not set in stone, and the dust has not yet
settled, the move towards a change away from the default branch name
"master" is currently happening.

Cheers.

-- 
Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Ismael Luceno]

Hi,

Probably like the overwhelming majority, I don't care about the
default changing, but for the sake of completeness, I must say:

This is a very USA-specific issue, and it's getting blown out of
proportion there, but basically the rest of the world pretty much
doesn't care.

Don't overlook the fact that the discrimination arises not from the
words you choose, but from the ideas and prejudices, embeded in
everything in your culture.

All these movements don't do anything real.

It doesn't fix the problems for those in our community suffering from
very real, intentional, abuse and discrimination, often done in a
soft-spoken manner.

It just makes a very few feel good with themselves because they did
something about a non-existing issue, and over their own
over-sensitive and skewed views of the world.

Moreover, it's just an unhealthy enablement of a bunch of pampered
thin-skinned nutheads nit-picking over language because they have
nothing better to do.

And if there's anyone that truly feels hurt by this kind of words,
they should use a dictionary, and if they still feel that way
afterwards, perhaps they should talk to a professional about their
feelings because what they're experiencing may be psychosis.

Quietly, some of us are trying to make the world a better place by
tackling real discrimination issues, and I can only feel indigtation
over how shallow the community is becoming.

Thanks.

El vie, 13 de nov. de 2020 a la(s) 05:30, Felipe Contreras
(felipe.contreras@gmail.com) escribió:
>
> On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> >
> > On 2020-11-13 at 00:04:23, Felipe Contreras wrote:
> > > *If* we are going to rename the master branch, it should be with a
> > > good reason, after discussing it appropriately, in a major release
> > > (i.e. Git 3.0), after a period of deprecation, and a big warning to
> > > invite users to provide feedback about the important upcoming change.
> > > We can hedge these types of changes with a "core.mode=next"
> > > configuration, as I argued back in 2013. [3]
> >
> > When the original email that proposed this change came up, I did suggest
> > that this would be suitable for a Git 3.0.  I think such a version
> > number bump would be valuable, but I know that Git doesn't follow
> > semantic versioning and I'm happy for Junio to make the call.  Git has
> > made incompatible changes in the past in non-major versions, so there is
> > precedent for this, although I agree it has the potential to be
> > surprising.  Again, I defer to Junio's judgment here.
>
> I have not been following the Git project for a while, but during the
> Git 2.0 development I proposed considerable drastic changes, which
> Junio said could not fit into v2.0, but perhaps v3.0, which according
> to him: [1]
>
> "Even if we end up having to wait for 3.0, it will happen within two
> years max, if not earlier." -- Junio 2014
>
> There are actual good backwards-incompatible changes that a new major
> release of Git would benefit from, so if Junio changed his mind about
> considering these types of changes, it would be good to know.
>
> I for one haven't noticed a single backwards-incompatible change since v2.0.
>
> > I should point out that there is an option to test or set this already,
> > with init.defaultBranch.  I have used this feature for testing in the
> > past, and I use the feature now to set default branches.  It's also
> > possible to use the template functionality to set a default branch name
> > for new repositories and I've tested support for this back to at least
> > Git 2.0 (but I believe it goes back even farther).  And, of course,
> > either of these options can be used for developers to choose the branch
> > name which meets the needs of the project best.
>
> There was also the option to test the future changes in v1.6.0, that's
> not the point.
>
> The point is that users **must be warned**--and very annoyingly
> so--before obsoleting something.
>
> > As for consultation with users, there was a discussion about this on the
> > list a few months back and we did get a lot of input from various
> > parties.  Some of that feedback was hostile and inappropriate and some
> > even violated our code of conduct in my view, as is all too common with
> > potentially controversial topics, and I'm not eager to repeat such a
> > discussion, since I don't think it's going to result in a productive,
> > positive outcome.
>
> I looked for this kind of discussion, but didn't find it. I didn't
> imagine it was as far back as June.
>
> It took a while, but I finally read the whole thread, and I understand
> your unwillingness to repeat such a discussion, but unfortunately it
> will have to happen again, because the people that participated in
> that discussion are but a tiny minority that is not representative of
> all Git users. If not now, it will happen in the future. This is
> exactly what happened in 2008, when the issue was discussed in at
> least three big threads.
>
> Moreover, my point was not discussed in that thread. You mentioned it,
> but everyone focused on tangents, such as the state of the culture
> war, and the etymology of the word "master".
>
> To try to save your sanity I will attempt to be brief (but probably
> not as brief as you would like to).
>
> This is what was discussed:
>
> 1. Adding a configuration (init.defaultbranch)
> 2. Should the name of the master branch be changed?
> 3. Best alternative name for the master branch
> 4. Culture war
> 5. The impact to users
>
> I have a lot to say about 4, 3, and 2, and perhaps I will do so in
> another thread, but that's not important, what is important is the
> thing that was not discussed: the users.
>
> I like to refer to a panel Linus Torvalds participated in regarding
> the importance of users [2]. I consider this an explanation of the
> first principles of software: the main purpose of software is that
> it's useful to users, and that it continues to be useful as it moves
> forward. To quote Torvalds:
>
> "Any time a program breaks the user experience, to me that is the
> absolute worst failure that a software project can make." -- Linus
> Torvalds
>
> This is the first thing the Git project should be worried about, not
> the current state of the culture war, and I didn't see anyone
> championing the users, and how this change will negatively impact
> their experience, which arguably has been pretty stable throughout the
> years (at least since 2008).
>
> That being said, I want to touch on only one point you brought
> forward, that is indirectly relevant to the users.
>
> You mentioned the importance of intent [3], and how we can never be
> certain of the intent of another person, this is true. However, we
> must try to guess what the interlocutor might have meant, otherwise
> there is no point in communication. This is realized in Wikipedia's
> fundamental principle of always assuming good faith [4], Grice's
> philosophical razor: prefer what the speaker meant over what the
> sentence they spoke literally meant [5][6].
>
> You cannot stand in a comedy special without realizing what the comic
> actually means, and it rarely is what he literally says. If I utter
> the phrase "kill me now", you know what I mean, or more importantly;
> what I don't mean.
>
> A lot of people today want to ignore this fundamental aspect of human
> language, and they do so for political reasons. But it doesn't stop it
> from being the case. It's not a coincidence that since 2005 nobody had
> any problem with the word "master", it's only in 2020 that the issue
> "magically" popped up. And it's no coincidence either what kind of
> people are pushing for this change.
>
> This is a solution looking for a problem.
>
> There is a concept called "the silent majority" which applies in
> software. Most Git users are not going to participate in culture war
> debates in the mailing list. It is usually a tiny vociferous minority
> that drives these kinds of discussions (and if it has to be said; I
> don't mean any negative connotation, simply stating that they are the
> opposite of silent). Even the users that are supposedly the target of
> these progressive changes (e.g. black users descendant of slaves) will
> probably not care at all about such changes, because they are part of
> the silent majority that uses common sense and understands that
> nothing ill was intended by the word "master". It is usually white
> people that "defend" these "oppressed minorities" without their
> consent, or need.
>
> Did we hear the testimony of a single black person that was offended
> by the word?
>
> The intellectual Gad Saad wrote about a disorder called Munchausen
> syndrome by proxy, and how it explains what many modern activists do:
> [7]
>
> "Munchausen Syndrome is where a person feigns illness, or medical
> conditions, to garner empathy and sympathy. Munchausen Syndrome by
> proxy is when you take someone who is under your care (your biological
> child, your pet, your elderly parent) and then harm that person or
> entity that’s under your care so that you can then garner the empathy
> and sympathy by proxy."
>
> Nobody affected by this change actually asked for this change, it is
> being done *preemptively* just in case some actual target user might
> find it offensive. The only people actually being offended are
> offended *by proxy*.
>
> I recommend the book The Parasitic Mind: How Infectious Ideas Are
> Killing Common Sense, which explains this and many more problems of
> the current culture war.
>
> I have a lot more to say about this, believe me, and perhaps I will do
> so in another thread, but for now the summary is this:
>
> We are going to *actually* harm true users that understand the intent
> behind the word "master" hoping we might benefit marginally some
> imaginary users.
>
> And if we don't warn them about the upcoming change, before the change
> is actually implemented (as we did with push.default), they will
> complain. Because unlike the users that are descendants of black
> slaves who misinterpret what Git developers meant by the word "master"
> and get offended as result--they are *real*, and they are a lot.
>
> Cheers.
>
> [1] https://lore.kernel.org/git/xmqqioq12eif.fsf@gitster.dls.corp.google.com/
> [2] https://www.youtube.com/watch?v=kzKzUBLEzwk
> [3] https://lore.kernel.org/git/20200614190842.GC6531@camp.crustytoothpaste.net/
> [4] https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
> [5] https://rationalwiki.org/wiki/Logical_razor#Grice.27s_razor
> [6] https://plato.stanford.edu/entries/implicature/
> [7] https://thoughteconomics.com/gad-saad/
>
> --
> Felipe Contreras

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Konstantin Ryabitsev]

On Thu, Nov 19, 2020 at 01:25:27PM -0800, Junio C Hamano wrote:
> The question most useful to ask at this point are to what name
> (fixed? computed?) and what the transition plan would look like.

Right, hence my statement that there are no "concrete plans." I've 
previously suggested that, should this change be implemented, it makes 
sense to couple it with another upcoming major compatibility break -- 
the sha1 deprecation. Perhaps we can start with the following:

Currently:

$ git init
Initialized empty Git repository in /var/home/user/foo/.git/
$

New:

$ git init
Initialized empty Git repository in /var/home/user/foo/.git/
 Initial branch: master
  Object format: sha1

Use --initial-branch and --object-format flags to specify other values.
$

> > It is misleading in the context of git, because it implies that a 
> > branch carrying that name is in some way special compared to other 
> > branches (e.g. like "trunk" in the SVN world). In reality, the 
> > "master" branch is just a branch like all others (and can be missing 
> > entirely or have junk in it), so it really shouldn't be called 
> > "master".
> 
> I find the above answer even more confusing, in the context of major
> projects and hosting sites all moving to 'main'.  If 'master' is
> misleading for all the reasons stated in the above paragraph, 'main'
> would equally be misleading.  In other words, "It is just a branch
> like all others, so it really shouldn't be 'master'" leads to "it
> shouldn't be 'main' or 'primary', either".

In my mind, there are important semantic differences between "main" and 
"master" that make "main" more acceptable. A town with a single road can 
reasonably call it the "main road." Similarly, a "mainstream" movement 
does not imply the existence of any other movements. Etc.

-K

Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Whinis]

> I couldn't agree more. We really need to be warning users several versions in advance,
> and I mean months or even years. I don't wan't to come up with a number, but I would
> guess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion
> on that topic ever took place.
>
> Brian mentioned that some people voicing their concern on the list did not abide by the code of conduct.
> There was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the
> discussion reached the mailing list, of which a lot was also considered to not abide by that project's
> code of conduct. While I agree that discussion should be done with respect, and some people that
> are driven to react to such important changes might not be aware of any code of conduct they should
> follow, because they don't participate in the "day-to-day" life of the project, just the fact that they even
> care enough to voice their disagreement should be a big red flag in terms of how this change should be done,
> in my opinion.
>
> I had avoided commenting on this whole subject, but the main point you are bringing,
> that such a change, if done, should be made with great care to our user base and a lot
> more warning, is a very important one.
>
> Thanks for bringing it up.
>
> Philippe.
Not just Git-for-Windows but there is also numerous reddit threads 
expressing both disbelief that this would even be considered and anger 
at how it might hurt various workflows as well as issues on gitlab and 
gitea which were closed as soon as any discussion started normally 
citing the code of conduct even if no real violations occurred. The one 
exception was gitlab where it was closed, reopened and allowed for long 
discussion before being closed again. In the gitlab one certainly user 
issues were brought up, even if primarily by me, before being discarded 
as those for the change purely on emotional reasoning. What I find sort 
of interesting is the constant claim that its a direct reference to 
slavery also without any proof.

Overall this is a massive change that will affect users, documentation, 
and classes for years to come if made and should only be made with 
clear, articulatable, realizable benefits such as the SHA1 change. 
Breaking years of documentation and books without that clear and obvious 
benefit is a disservice to users and likely to cause significant harm in 
the short and long term and a clear tenant of why few projects change 
things just to change things. The risk of unintended effects is too 
great once something is well recognized as python and others have found 
out trying to remove what their perceived as problematic language 
leading to multiple incompatible versions.

Whinis