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

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/

On 2020-11-13 at 00:04:23, Felipe Contreras wrote:

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.

On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

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.

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.

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/

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

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

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.

On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras 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".

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

On Fri, Nov 13, 2020 at 8:58 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:

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.

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

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.

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.

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.

On Fri, Nov 13, 2020 at 09:58:02AM -0500, Theodore Y. Ts'o wrote:

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

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

On Sat, Nov 14, 2020 at 02:19:59PM +0000, Lukasz Niemier wrote:

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

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

Which is precisely my suggestion: add a warning.

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

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.

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

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

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

On Wed, Nov 18, 2020 at 05:02:59PM -0800, Brandon Casey 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.

People want to be able to use arbitrary branch names.

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.

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

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

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

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.

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.

Correct.

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.

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

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.

On Thu, Nov 19, 2020 at 01:25:27PM -0800, Junio C Hamano wrote:

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

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

On Thu, Nov 19, 2020 at 5:37 AM Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

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

On Thu, Nov 19, 2020 at 3:29 PM Brandon Casey <drafnel@gmail.com> wrote:

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.

by the word?

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

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 Fri, Nov 13, 2020 at 12:02 AM D.E. Goodman-Wilson <don@goodman-wilson.com> wrote:

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.

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.

Hi Felipe, 

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.

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

More like 99.9%.

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.

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.

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