Rename offensive terminology (master)

"master" is an offensive term, as it can be interpreted as being slavery-origin terminology. See https://en.wikipedia.org/wiki/Master/slave_(technology)#Terminology_concerns

The Python programming language, and various other projects, have taken a stance and moved away from offensive terminology including "master". See https://bugs.python.org/issue34605

When different projects using git decide to move away from "master" as the name of their main branch, inconsistency ensues between projects. See https://github.com/desktop/desktop/issues/6478 (and "Related Issues and Projects").

To avoid offensive terminology and to avoid further inconsistency, I think git should use a different branch name than "master" when initiating a repo. I don't have a strong opinion, but I like "main" since it shares the first two characters and it's shorter.

On Mon, 4 May 2020, Simon Pieters wrote:

  please, no ... this is just massive and unnecessary churn, and it
opens up a ridiculous can of worms. if you change this, then of course
you will have to reword everything related to data buses that are
defined to work on a "master-slave" basis. and would you have to stop
describing your competence in a particular field as having attained a
"mastery" of the subject matter?

  this is just a bad idea.

rday

On Mon, May 04, 2020 at 01:43:15PM -0400, Robert P. J. Day wrote:

I would agree, this would be a huge can of worms. and is not really needed. the word "master" is embedded in our lexicon in many places. calling out one historical use, and then saying becuase of that use all the other uses can no longer use that word in our lexicon. is just a bad idea.

thats not how language should work.

-N6Ghost

On Mon, May 04, 2020 at 07:20:33PM +0200, Simon Pieters wrote:

Git doesn't use "master-slave" terminology -- the "master" comes from the concept of having a "master" from which copies (branches) are made:

https://simple.wikipedia.org/wiki/Master_recording

The concept predates the music business and goes back to middle ages when a guild master would create a "master work" or "master piece" that the apprentices could use for study or for imitation.

https://en.wikipedia.org/wiki/Master_craftsman

So, while I wholeheartedly support using inclusive language, I think git is in the clear here.

-K

On Mon, May 4, 2020 at 7:45 PM Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

Thanks. This may be so, but it's still the case that it can be (and has been) interpreted as being slavery-origin terminology.

If you decide to not change this, then I think it may still be good to add something like the above to the git documentation (like in [1] and [2]), so that projects using git are less inclined to change it for their projects, and maybe the people who are offended by it would be more comfortable if they know that the project maintainers are aware of this issue and could explain why this usage of the word is ok.

[1] https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefmasteramaster [2] https://git-scm.com/docs/git-init

On Mon, 4 May 2020, Simon Pieters wrote:

  uh ... i just popped over to that python.org discussion, and it does
not even *remotely* resemble what you describe. the gist of that
discussion is that most people seem opposed to a sweeping change, and
are annoyed about all the bandwidth that was wasted by one person
harping about this.

  based on what i read at that link, python has in no way "taken a
stance," so i'm calling you on your rather egregious misrepresentation
of what happened there.

rday

On May 4, 2020 1:54 PM, Robert P. J. Day Wrote:

even

stance," so

happened

If you are the repository owner on GitHub, BitBucket, or GitLab, you can change the default published branch to whatever you want, which is primarily where the publicly visible name would be - discounting private repos. "master" then becomes irrelevant and you can use "main" or "whatever". However, GitLabFlow depends heavily on the name being "master" for the workflow to make any sense. The OP might want to take this up with them.

-Randall

On 2020-05-04 at 17:20:33, Simon Pieters wrote:

I've been busy and haven't had much time to respond to this, but I've gotten some feedback from other people on this issue and so I'll share a few thoughts.

Others have pointed out that "master" meaning a canonical source may not share the problematic origins mentioned above. From feedback I've received, I get the impression that "master", even though from a different origin, brings the idea of human bondage and suffering to mind for a non-trivial number of people, which of course was not the intention and is undesirable. I suspect if we were making the decision today, we'd pick another name, since that's not what we want people to think of when they use Git.

Clearly we have compatibility concerns to consider though, so if we decided to make a change, we'd probably want to make it in a 3.0, which as far as I'm aware hasn't been discussed yet. I also wondered what such a change would involve, so I did some research.

It appears that if we made the obvious one-line change to builtin/init-db.c, we'd have 304 tests that fail, which is about a third of our test suite. I haven't examined any of these tests, so I don't know what would be involved in changing them. I imagine a project to do so would involve setting an environment variable in the test setup code (e.g., MAIN_BRANCH) and replacing instances of "master" with that until everything works with an alternate value of that variable. Picking the new name itself could be deferred until later, and we could choose from some popular alternatives.

There's also the documentation, which at first glance seems mostly to be examples, many of which could be changed to any suitable branch name. There are a large number of those cases and someone would have to audit them all.

So it looks like this would be a reasonable amount of work for someone if they decided to pick it up as a project. Since I have limited free time and am working on the SHA-256 transition, I won't be doing this, but if someone did pick it up, I would be happy to do some reviews, provide feedback, and include a few patches while doing other work in the area.

I realize there isn't agreement on a direction forward or whether this is worth doing at all, but since Git usually operates by providing feedback on an initial set of patches, I thought I'd sketch out what that might look like for folks who were interested.

I should point out that it's also possible for users who dislike the current name to use a template to change the default branch name like so (using the proposed "main"):

  mkdir -p ~/Templates/git
  cp -a /usr/share/git-core/templates/* ~/Templates/git
  echo 'ref: refs/heads/main' > ~/Templates/git/HEAD
  git config --global init.templateDir ~/Templates/git

Then "git init" will set your default branch to "main" instead of "master". This does have the weirdness that it claims it's reinitializing your repository, but otherwise appears to work. That is of course orthogonal to changing Git itself, but is an option for folks who'd like to make a change now.

Thank you for your encouraging response, Brian, and the research of what the change entails for git.

I've added Don to the cc, who started to work on implementing this change:

https://twitter.com/DEGoodmanWilson/status/1269931743320182784 https://github.com/git-for-windows/git/issues/2674

Although I think it's reasonable to move away from 'master' regardless of its origin, today Tobie Langel pointed me to https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html where, one year ago, Bastien Nocera made the case that git's 'master' is in fact a reference to master/slave.

If someone is interested in helping with this, please follow up with Don. But I would like to ask again for git mainline to seriously consider adopting this change, given the information presented above and the ongoing movement against systemic racism.

cheers,

On Wed, May 6, 2020 at 1:17 AM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Simon Pieters <simon@bocoup.com> writes:

I am OK in principle if a future version of Git, when used by a new user of Git who does not have any custom configuration, wrote a string other than 'master' in .git/HEAD when "git init" is run.

Picking a good replacement word to mean the primary branch is tricky, though. Just having a notion that one is special among many (i.e. the primary-ness of the thing being named with a word that will replace 'master') may already be offending to some folks.

Also notice that the qualified statement above talks only about the plain vanilla experience---the change of the default should be designed to avoid harming workflows in existing repositories and tools built around them.

So, I think there are two separate tasks that can run in parallel.

 * Pick the new default word to replace 'master'; it may turn out
   that the Git project choose not to pick any to avoid offending
   anybody, in which case "git init" may force end users pick the
   default they want to use and offer recording in the ~/.gitconfig
   file.

 * Engineering work that uses the word that replaces 'master' by
   default (if one got chosen) when not configured, and use the word
   the end user chose when configured (iow, allow users to override
   the default word that will replace 'master').  This includes
   design work to decide what to do in existing repositories (if
   there is anything that needs to be done).

Without digging deeply, I think we are pretty good about basing things on HEAD (e.g. "git branch -d" protects the branch by seeing if it is already merged to 'HEAD' or its @{upstream}, and not treats 'master' any specially), so it might be the matter of teaching "git init" (it uses 'master' by default) and "git clone" (it tries to use the name of the branch the HEAD at origin points at, but falls back to 'master' when the branch name their HEAD points at cannot be determined).

On Tue, 9 Jun 2020 at 18:05, Junio C Hamano <gitster@pobox.com> wrote:

I work on two git repos where we renamed "master" to something else. Both have been in heavy use for years, and I don't recall ever hearing about any issues related to the branch rename except in dumb scripts. FWIW we renamed because we felt talking about the "master branch" in a distributed context would lead to confusing expressions like "the master master". Using something else avoids this double word formulation. I definitely find it less confusing when talking about the branch topology of these repos as opposed to the defaults.

Yves

Am 09.06.20 um 18:02 schrieb Junio C Hamano:

Don't forget the special treatment of "master" in fmt-merge-msg.c that skips the " into 'foo'" part of "Merge branch 'bar'".

-- Hannes

Johannes Sixt <j6t@kdbg.org> writes:

Yup, that certainly needs to be taken into consideration in this topic. There may be more that we are forgetting.

Hi Junio,

On Tue, Jun 9, 2020 at 6:02 PM Junio C Hamano <gitster@pobox.com> wrote:

I find this response not satisfactory:

- as far as I can tell, no evidence that "main" offends anyone.
- git trying to be neutral by not having any default name seems like a
weak response to this issue.
- having users have to pick a branch name when initiating a repo
increases the burden on users and makes the learning curve steeper for
beginners.
- git not being opinionated on the branch name doesn't address the
inconsistency problem pointed out in the original post.
- while git itself could avoid having a default branch name, platforms
that use git such as GitHub or GitLab will still likely want a
default.

I think git can lead the way and make things inclusive, consistent, and not regress on usability.

cheers,

-- Simon Pieters Bocoup https://bocoup.com/

Simon Pieters <simon@bocoup.com> writes:

And I find that response quite offensive.

I am not saying that there is any good replacement word, or there shouldn't be one, or we shouldn't look for it. If we can come up with a single replacement word and everybody can agree on it, that would be great.

I am just cautioning you that we may not be able to reach a single word as a concensus, and you should plan with the possibility in mind.

In any case, I wasn't responding to satisfy just you in particular anyway ;-)

On Tue, Jun 9, 2020 at 11:03 PM Junio C Hamano <gitster@pobox.com> wrote:

I'm sorry I offended you.

OK. I agree!

OK.

Yeah, and indeed this issue is not about me. :-)

On Tue, 9 Jun 2020, Simon Pieters wrote:

  ... snip ...

"I can't breathe ... I can't breathe ..."

"Well, tell you what, what if we rename the initial default branch in a distributed version control system for you?"

  *Now* do you understand how asinine all this sounds?

rday

May I just add to this part of the conversation by pointing out that if people are concerned that the use of the word "master" for the main branch name is offensive, there will also need to be subsequent consideration for the name of the project itself: "git" is, for some, nothing more than derogatory slang with no particularly positive connotations.

It becomes arguable that if people wish to avoid (for example) the upcoming generation from acclimatising/normalising usage of the word "master", that same principle could also encroach upon the name of the tool itself.

Share and enjoy.

K

On Wed, 10 Jun 2020 at 11:51, Robert P. J. Day <rpjday@crashcourse.ca> wrote:

Robert,

If this were the _only_ effort being made, I would agree. It's a small thing. But lots of small things add up, and they make the big things worse. So, because it is small doesn't mean it's not important, or that it can be ignored. Indeed, that is a sign of privilege, to be able ignore the small things that seem unimportant in isolation. Thus, of course this is not the only action I am taking at present, I take a multi-faceted approach to my activism, and I encourage you to do the same.

I think my friend Mislav has a much more eloquent response that is worth reading: https://twitter.com/mislav/status/1270388510684598272

Don Goodman-Wilson

On Wed, Jun 10, 2020 at 11:51 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:

On Wed, 10 Jun 2020 at 08:18, Don Goodman-Wilson <don@goodman-wilson.com> wrote:

Curious, what are your plans regarding your Master of Arts degree?

-K

Could you please take your activism somewhere else? I'm kind of sick of entitled, rich, virtue signaling americans trying to make their problems everyone else's problem too.

 >as far as I can tell, no evidence that "main" offends anyone.

I'm offended by "main". What now?

Sérgio Augusto Vianna <sergio.a.vianna@gmail.com> writes:

You make sure that the list won't reach concensus that the word is good enough for everybody.

Even if you fail in doing so, there still is a recourse for you.

When you see a (future) version of Git that allows you to configure the name of the default/primary branch, but does not yet switch the name of the default/primary branch from 'master' to 'main', you set the configuration variable(s) to 'master' (or whatever word of your choice) in ~/.gitconfig and move on. You won't be affected by the future switch from 'master' to 'main' by being prepared that way.

Then why create all this disruption by changing the default from master to "main" if you will offer a feature to set the default on creation? Americans were discussing trump's tiny hands last week and will have moved on to any other meaningless subject the next one. You can literally never please the perpetually offended. Taking this kind of slacktivism and creating problems for other people is a disgusting level of entitlement that only americans display. You really care about others? Remember there's other countries in the world.

I am an American living in Europe. Let me offer an analogy. Like all analogies, this one is imperfect, but I think it will serve to make my point.

As an American, I don't understand French humor. It's simply beyond me. I've had it explained to me numerous times, but of course explaining a joke can't impart its inherent humor. But none of this should come as a surprise to anyone, as humor is a deeply cultural artifact, something that can only truly be understood by those raised within that culture. Even so, we can all appreciate the concept of humor generally. More to the point, I certainly don't go around denying that French humor exists, on the basis that I don't get it.

In the same way, something I've learned living in Europe is that many (if not most) non-native English speakers realize just how explosive certain English locutions can be to American native speakers. That's totally understanable as, like French humor, you have to have been raised in the culture to really understand that fact. Like humor, we all have a sense of what offensiveness means, and like humor, this explosive content is a deeply cultural artifact, something that can only truly be understood by those raised within that culture. The visceral feeling of explosive content will probably always be beyond grasping, just as French humor will probably never make me laugh.

But to deny that explosive content on the basis that you don't personally feel it, that you've never experienced it? To claim that it is "meaningless", that some people are "perpetually offended"? That's willful ignorance on your part, a bad-faith effort to engage in serious intellectual conversation about what is good and right, and has no place in a discussion about creating an inclusive space for all developers, let alone trying to bring about a more just world.

Don Goodman-Wilson

On Sun, Jun 14, 2020 at 2:50 AM Sérgio Augusto Vianna <sergio.a.vianna@gmail.com> wrote:

(Sorry, I meant "many (if not most) non-native English speakers DON'T realize just how explosive certain English locutions can be to American native speakers.")

On Sun, Jun 14, 2020 at 8:32 AM Don Goodman-Wilson <don@goodman-wilson.com> wrote:

Americans' perpetual offendedness with everything is what leads to what was written in Fahrenheit 451. Constant obsession with offendedness and constant valuing of everyone else about "should I be offended now?" is so much American now it became really concerning among all this PC culture. Won't you stop your great self-destruction guys?

On Sun, Jun 14, 2020 at 9:36 AM Don Goodman-Wilson <don@goodman-wilson.com> wrote:

And I'm also offended by "main"

On Sun, Jun 14, 2020 at 11:47 AM Sergey Lapin <slapinid@gmail.com> wrote:

Ok, first of all, "making a better world". Get off your high horse, ok? This is a version control system, an engineering tool. This change is 100% meaningless and will bring literally zero impact to the world except the disruption in people's workflow. Second, this is a GLOBAL community. It does NOT revolve around americans is it NOT used exclusively used by americans. Let's assume just because a handful of people (by the way, only 8% of americans are progressive https://hiddentribes.us/profiles/) feels in a certain, does that means we should make changes like this because of any other people? Indians find it offensive that people eat cows. Muslims find it offensive that homosexuals are alive. French find it offensive when you don't take wine seriously. Chinese find black people offensive. Polish find communism offensive. Brazilians find classism offensive. Are we going around making all these slacktivist changes just because someone, somewhere might remotely feel offended by it?

Not only the original proposal comes from an absurd point of view and is just an excuse to say one is offended, but it also demonstrates just how entitled it is by ignoring that there are many others points of views and each one would be as valid to enact a plethora of other meaningless and pointless changes. Because let's not forget a very, very important aspect here: MASTER IS NOT INHERENTLY RELATED TO MASTER-SLAVE RELATIONS. It was pointed before but people keep willingly ignoring it: YOU JUST WANT TO BE OFFENDED. This is why I say "perpetually offended". You don't need to propose software changes likes this, you need therapy.

On Sun, 14 Jun 2020 at 08:35, Don Goodman-Wilson <don@goodman-wilson.com> wrote:

Well said sir. I might quote that sometime.

Cheers, Yves

On Tue, Jun 16, 2020 at 09:31:43AM +0200, demerphq wrote:

No. The stupid idea. The stupid discussion. All world use this terminology and it disturb nobody with sane mind. And why we must change it? Because someone is completely mad and takes this as an insult to himself? There are many *real* problems in the world - famine, wars, drought, diseases, etc. What do you know about this? Where is you HELP? Fucking hypocrites. All of you have well-fed life - you know nothing about real problems. Do you think you can just rename something in you fucking code(JUST REPLACE ONE LETTERS WITH ANOTHER ONE) and this helps somebody? Are you all really so stupid? If you want to help, just lift your ass from a chair, toss a hamburger and go to the street, find someone who need help and HELP HIM. Just help somebody! But this is so hard. Real things are always hard. Every day you need to do something to make this world better. This is not what we want. We want just to sent $10 sometime to some charity organization or change several letters in our computers. Yes? This is so simple. Just do it and feel better, liers.

Whole technical world look at you now and think:

"These men are comlete idiots. They really think that changing letters will change something in real life".

If some of you don't want to write a code and want to do some politics, just leave and dedicate your life to politics. Why should we all suffer from someone's polical program? This is not the property of someone. This program is used all over the world. Did you ask somebody outside of your sandbox, boys? Do you really understand the responsibility?

On Tue, Jun 16, 2020 at 1:39 AM Oleg <lego_12239@rambler.ru> wrote:

...

...

Please stop. Bringing up reasons why proposed changes would or even might cause harm are perfectly welcome, especially if details and examples can be provided. (In fact, it would be a lot more helpful than simply asserting that the change would be very harmful.) Name calling is not okay.

Emails like this one from you are not wanted and not welcome within this project. Please go read the project's Code of Conduct (https://git.kernel.org/pub/scm/git/git.git/tree/CODE_OF_CONDUCT.md) and only continue to communicate with this project in ways that are in alignment with that code.

Elijah

Yes, that is why CoCs are implemented - to shut up everyone and do the right thing. Congratulations on your winning. There is nothing else to show what the state people are in. Please get well.

On Tue, Jun 16, 2020 at 10:37 PM Elijah Newren <newren@gmail.com> wrote:

On Tue, Jun 16, 2020 at 12:33:18PM -0700, Elijah Newren wrote:

ok, but what do you talk about, Elijah? Here ault men talk about serious things. If you have something to say on the topic, you are welcome. You can do it in any form - we will try to understand you. Otherwise, please don't waste our time. The ethics club is elsewhere.

Elijah, it would be a lot more helpful if you read the thread. Here not only me already wrote about various reasons why this change is bad. And we didn't see at least one technical reason why this is good. Just politics speaches.

Two really important reasons:

1. This setting need to *very-very small* count of people.
2. The future default value of this setting will break *many* projects and
   people stable workflow.
 
So, why we need this? Because now one country have some *internal* troubles
(this is sad, but the code isn't to blame for this)? And why the whole world
need to suffer from this situation? I think some people here don't understand
the moment. Don't understand the consequences. This project is not your
personal project, Elijah. It isn't even american. Why billions of people
should to suffer? Because of white american's chauvinism? I think some people
here don't understand the responsibility to the world for their actions.

If anybody is intrested in git users opinion(not github PR-man or PR-man of any other monster company), then he can simply read it here:

https://www.change.org/p/github-do-not-rename-the-default-branch-from-master-to-main

Elijah, my english is bad, i can't understand this document. Sorry. I think this is a discrimination of non-english speakers. Why no translations?

Whether or not any patch would be accepted, the damage is already done. From now on, people will judge you if you dare to use the name "master" anywhere and this is incredibly sad. These people are literally bullying us into submission in the name of political correctness where no harm was actually done.

This sickens me.

16.06.2020, 13:31, "Alex Smith" <alexsmith@gmail.com>:

I guess their next move might be to force sound engineers to rename master channel and derived term "mastering" into something more politically correct.

On Tue, Jun 16, 2020 at 02:29:49PM +0300, Konstantin Tokarev wrote:

What?!! Are they still use these amoral terminology?!! That's sad...

On Tue, 16 Jun 2020, Konstantin Tokarev wrote:

  nicely done ... a masterstroke of rhetoric.

  damn it ...

rday

Konstantin Tokarev <annulen@yandex.ru> writes:

There is even better target:

$ cd src/linux $ find . -name '*.[ch]' | xargs grep -i '(master)\|(slave)' | wc -l 40506

... and then they'll finally be on the right track to win the war against it.

-- Sergey

On Tue, Jun 09, 2020 at 05:16:57PM +0200, Simon Pieters wrote:

Well, he pointed out that Bitkeeper used this terminology. Git doesn't have any internal concept of "slave" -- the only time you see this word used in the codebase is in the test suite, and we should absolutely change that.

I am torn on this issue -- I certainly want the project to be inclusive to all, but English has a lot of concepts that start with "master" and do not trace their origin to subjugation of fellow human beings:

- masterpiece
- masterful
- master's degree
- master copy

Making this change in git seems like attacking the problem at the wrong end.

Branch names are already fully arbitrary in Git -- you can have a repo without a master branch. Perhaps the best way to address it is to introduce a "default branch name" configuration variable, or just work without any default branches and let the next step after "git init" be "git branch".

-K

Konstantin,

My feelings generally are: if you have to explain why it isn’t racist, then there’s probably a better alternative. But in this case it appears the roots really are in problematic terminology.

Anyway, you’ll be pleased to know that as a first step, my current work is focused on making the default branch name configurable via `git config` or environment variables. I’m working on a good clean patch for that functionality this week. I'll share more once the patch is looking better.

Don Goodman-Wilson

On Tue, Jun 9, 2020 at 6:06 PM Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

No one here has to explain why something not racist is racist. The problem are the perpetually offended that see racism in literally everywhere. Specially when there's virtue signaling points in the table.

On 2020-06-14 at 00:05:33, Sérgio Augusto Vianna wrote:

I want to take a second to respond to this because I think there's something this discussion may be missing that I want to make explicit.

When we use language, that language has a context. Part of that is situational and part of it is based on how the receiver perceives it. Very little of it actually comes from what the actual intent of the sender is, because we can't be 100% certain of the sender's actual intent without explicitly asking them (and not always even then). Even if we can, that doesn't usually change the perception of the receiver, so it doesn't change the message that was received. And it's important to note that the message that was sent and the one that was received can be very different.

There is nothing we can do to avoid this context because it's inherent in language and in the enormity of human experience. We can only control what context we deliver to others by being aware of how other people perceive our words.

I'd like to illustrate this with an example from my own experience. In Britain, the word "faggot" refers to a type of meatball which many people enjoy. In many English-speaking countries, it's also a slur for a gay, bisexual, or queer man. Even if, when I hear that word in a culinary context, I can objectively tell myself that the word is meant with neutral intentions, it still brings to mind the fact that I and many of my friends have been called that and with that, my experiences of discrimination and harassment. One could say that I'm just easily offended, but whether I want to be reminded of those experiences or not, I am. My mind just goes there. The context here has nothing to do with the sender, who probably meant well, but the message I received in, for example, reading a restaurant menu, was a negative one.

A reasonable person who wants to communicate well will be aware of this context and will choose to use a different phrase if they don't want to communicate that negative context. For example, the restaurateur may choose to use the phrase "savory ducks" on their menu instead. If they choose not to, then we may draw conclusions about their intent when they use the language they use.

Similarly, when we use the words "master" or "slave", even in contexts where they have different meanings, we send context along with that use. Black people, although able to objectively distinguish the two contexts, may receive a reminder that they or people like them have been subject to bondage, inequality, oppression, or discrimination. If that is not the context we wish to send to them, then we should consider using different language. Nothing prevents us from using those words except for our desire to communicate or not communicate a certain context.

And while I admit that in this discussion one may say that one word is an obvious slur and one is not, that doesn't mean that the context the receiver receives is necessarily that different. It may vary in its intensity, but the underlying negative context may still be there.

I do want to underscore that free software is not exempt from this phenomenon because we use language, and all communication with words is subject to these same limitations and to the human experience.

The proposed patch series makes the branch name configurable, so you may choose to use a default branch name which suits you. It sounds like you may choose to stay with "master", and you are welcome to make that decision. However, as with all language, that comes with context, and others will receive and interpret that context and draw their own conclusions about your intentions.

On a final, slightly different note, I also want to remind folks that are here that we have a code of conduct, which encourages us to use welcoming and inclusive language and be respectful of differing viewpoints and experiences, and to refrain from insulting or derogatory comments. I know that this isn't always easy, but I encourage community members to consider their comments carefully with that in mind, especially when feelings are as strong as they are here. If you want to take some time to remind yourself of what it says, it's available as CODE_OF_CONDUCT.md in the root of the repository.

So tell me, how many people have to be offended for a change to be made? Because obviously you will never find a word that doesn't offend anyone. So where is the compromise? I know that the VAST MAJORITY of people wanting this change here are white, including the OP. I am POSITIVE their motivation is nothing beyond virtue signaling.

And on a second note, this is why COC are harmful. They are just a way to justify injecting agendas and coopting projects. There shouldn't be a mandate of "inclusive language" to begin with.

Hi brian,

On Sun, 14 Jun 2020, brian m. carlson wrote:

Thank you for sharing your perspective with us; As it contains very personal parts, I am particularly grateful that you chose to write it out in public.

And also: I cannot agree more with you.

Ultimately, it is the empathy that matters. If a certain term does not offend me, but is hurting other people, then changing that term is not about me. My involvement in this comes from my desire to offer my support.

I feel the exact same.

When I originally read Simon's initial mail, and one of the responses, I felt that the analogy to the music industry made a lot of sense. And that the amount of work to change a default that has been with us for fifteen years was just too much. I guess I am not very alone in this.

In the meantime, I had many private conversations that clarified the big picture for me. I cannot in good conscience continue to use the current default main branch name, and am actively working toward changing it in all of my repositories.

I am glad that you brought this up. There has been overwhelming support for this code of conduct by the active contributors to this project. It is ultimately benefitting the project that we chose to make that code explicit.

Ciao, Dscho

Hi brian,

On Sun, Jun 14, 2020 at 07:08:42PM +0000, brian m. carlson wrote:

Thank you for this thoughtful and personal response. I appreciate you sharing your perspective, and I think that it is helpful, patient, and powerful.

I want to echo this as much as I possibly can. Language has meaning. Sometimes intentional, sometimes unintentional; but words matter, and words can hurt. Changing the name of the default branch away from 'master' is not intended to solve all of the world's problems, nor will it. But, it's a small thing that we *can* do to make a difference in *this* project.

If we take the argument that our efforts here are being wasted because of other uses of 'master' in the English language, then nothing will ever get done since everybody will always be waiting on everybody else.

Doing this is the right thing to do. It is *easy* for us to do, given our extreme privilege, and it should be done.

Thank you for highlighting the many ways that language and our choice of words matters and affects people. I understand that this is a deeply personal experience that you are sharing on the public mailing list, and so I thank you for your courage in using your voice to do so.

I think that I am on a slightly different topic by now, but please note that this change does not *break* anything. It doesn't force people to change the names of their branches. Any user of Git is welcome to name their branches however they like, so long as they accept the consequences of doing so.

Thank you. It is for exactly these situations that the CoC is useful. Nobody--certainly not you--is trying to force any ideology on anybody.

The CoC should serve as a reminder to us all that there are people on the other side of our emails, and that we should treat those people with respect, and as we would ourselves wish to be treated.

Thanks, Taylor

And how many people care about this meaning? 1, 2, a dozen? You all keep forgetting this will disrupt the workflow of THE WHOLE WORLD. Why don't you run a poll? See how popular this would be. See what would be the odds of a fork happening. This is NOT EASY. Also, is still pretty telling the vast majority of people here are white, rich and american but love to speak for the poor, oppressed and blacks.

On 2020-06-09 at 15:16:57, Simon Pieters wrote:

I'm familiar with those discussions. As previously mentioned, I'm happy to review any patches that come up and contribute myself as time allows.

I agree with the assessment that we should change regardless. If it is a master/slave reference, then that would be even more compelling as a reason to change.

Hello,

On Tue, Jun 09, 2020 at 05:16:57PM +0200, Simon Pieters wrote:

I think it's not. The word 'master' on its own without pairing it with 'slave' does not automatically imply slave master.

As has been pointed out it may mean central person to an organization, a skilled person (as in a person who has mastered a skill or teching) and most applicable to VCS something alike master document, master copy, master mix, etc.

Implying the worst possible meaning points to bias and prejudice.

Fighting bias and prejudice (ie racism) with another bias and prejudice might seem to provide relief short time.

However, so long as bias and prejudice remains no progress is made.

If we embark on the misson to eradicate all and any words that can be undurstood as offensive in any context from all general language regardless of context we will soon have no language left.

People keep repeating that words have weight. That's certainly true. However, there is the other side of the argument. We are not completely powerless to the weight the words carry for each of us, personally.

Great minds have came up with the option to reclaim words that we feel are offensive in our personal vocabulary by examining where the offense comes from and if there is positive meaning we can attach to the word in question.

The effort should be spent on both sides. Otherwise this becames childish, immature rampage. Some of the changes suggested as part of this kind of acticism already look that way.

As has been pointed out already even in BitKeeper the use of master/slave it the exception rather than the norm.

It is common terminology used in database replication schemes and BitKeepr being a sort of database it has been used to describe similar schemes in the documentation. It has nothing to do with the naming of the master branch in git.

With databases the suggested replacement is primary/repllica. With git the replicas are made with the clone command which lends itself to naming the replicas as well.

That all said there is nothing preventing projects using git today to use different branch names. Many projects exist that don't have a 'master' branch either for reasons of activism or simply beacuse it is not fitting to their development workflow, they use localized branch names, or whatever. Also the master copy meaning is typically not what non-native English speakers would understand.

What is brewing as response to this request is a feature that makes creating and using projects without a 'master' branch work more smoothly for the general user which is a good thing.

Kudos to git maintainers for handling this sanely. In the past not well thought out responses to requests like this caused a lot of grief and negativity towards the software in question and this kind of activism in general.

Thanks

Michal

Hi all,

On Tue, 5 May 2020, brian m. carlson wrote:

Indeed.

I have to admit that I did not understand the breadth of how problematic such a term is. I am a Caucasian male, and in the society in which I grew up, that comes with a lot of privilege that I am only beginning to understand in its entirety. One of the consequences was that I was unaware, even oblivious, to the emotional response certain terms can elicit. Just because those terms do not affect me very much, personally, does not imply that I don't care. So I will try to do my share in helping with this topic. It might not be much, in the bigger picture, yet together with other, equally small steps, we might be able to do some good.

A growing number of projects does indeed rename their default branches, and I want to do the same with Git for Windows' repositories.

I have reached out to Billy Griffin (the PM of GitHub Desktop) to learn what might be good candidates for the default branch name, as GitHub Desktop changed their repository's main branch name recently. This is what he told me:

	[W]e did some research looking at the data at GitHub of the most
	commonly used default branch names other than `master`. Most of them
	were things like develop, release, staging, stable, production, etc.
	that denoted some stage of the software lifecycle. We thought that
	none of these are good options because a universally applicable
	default name should allow for teams and projects to work in
	different ways (and obviously if teams want to change it to reflect
	their workflows, they're free to do so just like they do today - we
	use `development` as the default branch in desktop/desktop, for
	example).

	The three most common names that *weren't* in that category were
	main, trunk, and source. "Trunk" has roots in SVN so there's some
	precedent for it, but we've heard feedback that it's not
	particularly intuitive for non-native English speakers, and "source"
	in my opinion isn't accurate because it's only a single branch, not
	the entire source. We've also seen "default" floated and it exists
	in mercurial, but we've also heard feedback that it's potentially
	sensitive due to financial default, so we might as well choose
	something else if there's another good option.

	For that reason, we're thinking that `main` would likely be a good
	choice because the name corresponds nicely to its purpose as the
	default branch of a repo. It's also conveniently short to type,
	and tab complete would continue to *just work* for those concerned
	about muscle memory because the first two letters are the same as
	`master`.

So I plan on using `main` for the repositories in the https://github.com/git-for-windows org.

Billy then shared this information with James Ramsay of GitLab to discuss how GitHub and GitLab can coordinate on changing the default branch name in new repositories. Here is the GitLab ticket to track their progress: https://gitlab.com/gitlab-org/gitlab/-/issues/220906

As mentioned elsewhere in this thread, Don (Cc:ed) and I started working on this, and I just submitted it: https://lore.kernel.org/git/pull.656.git.1591823971.gitgitgadget@gmail.com/ That patch series adds a config variable allowing to override the default name of the default branch.

I hope to see this finalized and sent off to the Git mailing list relatively soon: being strictly opt-in, it should be really uncontroversial and obviously helpful.

Indeed.

The good news is that this audit can be split between multiple volunteers.

Based on the above-mentioned patch series, I have an end-to-end proof-of-concept (with one or two monster patches that still need to be split up) to change the default branch name to `main`. It is complete in the sense that it passes the test suite (also in SHA-256 mode when merging the `bk/transition-stage-4` branch), but it has a couple of too-large commits that still need to be split up: https://github.com/gitgitgadget/git/pull/655

I agree with brian that it was _quite_ a decent amount of work, and that it will still require a decent amount of work going forward.

My current plan is to split this up into several patch series:

- above-mentioned patch series was already split out, and submitted for
  review, introducing `core.defaultBranchName` (and
  `GIT_TEST_DEFAULT_BRANCH_NAME`).

  From my point of view, this would be safe to have even as early as
  in Git v2.28.0.

- a patch series that tackles the hard parts of the test suite: one by
  one, the test scripts will be patched to include

	GIT_TEST_DEFAULT_BRANCH_NAME=main
	export GIT_TEST_DEFAULT_BRANCH_NAME

  at the beginning, and they will be patched to pass.

  This patch series should only be accepted once there is consensus (see
  below for more on that).

- a patch series to tackle the easy parts of the test suite, i.e. the
  scripts that needed only automated patching (`sed` magic).

  This patch series should only be accepted once (if!) the previous one
  was accepted.

- a patch that moves the GIT_TEST_DEFAULT_BRANCH_NAME assignment to
  `t/test-lib.sh` to ensure that the entire test suite passes with the
  designated new default branch name.

  This patch really only makes sense once consensus is reached not only
  that we want to change the default branch name, but also to what name
  it should be changed.

  The main intention of this patch is to ensure that the test suite keeps
  working with the new default branch name during the (probably quite
  long) time when Git holds off from "flipping the switch", i.e. until the
  above-proposed Git v3.0.

- a patch series that changes the default, and then addresses all of the
  documentation and the error messages mentioning the default branch name.

  This would conclude that effort.

Or maybe there are a couple more natural seams at which to partition those patches better, to improve reviewability (and to reduce reviewer fatigue).

Thank you for doing this.

As you hint, there are the technical challenges, but also the cultural challenges. I think I outlined a sensible path forward to address the technical challenges above, and now I would like to talk about a path forward to address the social/cultural ones.

I do realize, of course, that as a white person identifying as male, there is a real big risk that my efforts look as if I want to force everybody to accept a new default branch name, to adjust their tools and scripts, their workflows, for maybe not a big enough gain to be worth all that work.

So let me make my intentions clear: I do care about inclusive language, and even more so about inclusive culture, and I would like Git to be changed accordingly.

And as I learned from personal conversations with friends and colleagues, as well as from stories and books, Git's current default branch name is eliciting emotional distress.

Encouraged by Emily in #git-devel (who pointed out that a subject like this is much better discussed seeing each others faces and hearing each others voices), I would like to organize another Virtual Contributor Summit, this time focused on inclusive language in Git, what we can do about it, and what we should do about it (or not).

Tentatively, I would like to propose having this meeting in the coming week, via Zoom, just like we did the Virtual Contributor Summit last September.

Could I ask all interested parties to reply to this email?

That's a pretty good workaround in the meantime.

I would like to point out that there are two slight issues with this workaround, in addition to the "re-initializing" message:

- copies of Git's templates can become stale during upgrades, as newer
  versions of Git might come with modified template files.

- Git's template files are sometimes used to install a set of hooks that
  was aggregated by the administrator(s). This workaround would interfere
  with that, at least if the set of pre-configured hooks gets modified.

For those reasons, I hope that the `core.defaultBranchName` patch will be on its way into git/git soon.

Thank you, Johannes

On Wed, Jun 10, 2020 at 11:30:31PM +0200, Johannes Schindelin wrote:

Yes, I'd like to be in attendance; this is a fundamental change that's relevant to the libgit2 project's interests.

Thanks- -ed

On 2020-06-10 at 21:30:31, Johannes Schindelin wrote:

I appreciate you working on these patches and also your consideration for the SHA-256 work.

I think if you can split out the automated portions into their own patches, then it will be easier to review. It sounds like you're already planning on doing that, so I don't have many other suggestions. I look forward to seeing the patches.

Thank you for saying this. I agree wholeheartedly, and I feel very strongly that the words we use matter.

I'm interested in participating as well.

On Wed, Jun 10, 2020 at 11:30:31PM +0200, Johannes Schindelin wrote:

...

Indeed, the flexibility to choose the name of the default branch can be helpful for projects with specific naming, especially non-english speaking projects.

To that end I would suggest adding -b argument to git init to be able to choose the default branch name per project. This should select the initial branch name and also write the it as the default branch name in the repo configuration (if git continues to treat the default branch specially).

This can be used in documentation to use the new name immediately without breaking existing workflows that rely on the 'master' branch.

The default branch name will not be preserved across clones but today projects that choose different default branch name don't get the default branch special treatment in anyway clones so I don't see that as a regression.

Thanks

Michal

On Thu, Jun 11, 2020 at 1:52 PM Michal Suchánek <msuchanek@suse.de> wrote:

I _really_ like this idea (and your reasoning). Seconded.

Don Goodman-Wilson

On 6/11/2020 7:59 AM, Don Goodman-Wilson wrote:

Yes, adding a -b|--branch option would be an excellent addition to the config option.

Thanks, -Stolee

Derrick Stolee <stolee@gmail.com> writes:

In the ideal world, users should be able to just set init.defaultBranchName in ~/.gitconfig once and forget about it. But it is expected that some projects and their tools may heavily depend on the assumption that the primary branch is called 'master'. Giving a command line override like "init -b" (and do not forget to do the same for "clone" as necessary) is a good escape hatch for members of such projects.

Good.

Hi,

On Thu, 11 Jun 2020, Junio C Hamano wrote:

I agree, and I incorporated this already in the latest version I pushed to https://github.com/gitgitgadget/git/pull/656.

Ciao, Dscho

On Sun, Jun 14, 2020 at 04:59:32AM +0200, Johannes Schindelin wrote:

Why should everyone use the same branch names?

It makes more sense for people to name their branches in a way that makes sense in the context of their project/workflow/language.

Showing the use of -b with init in tutorials and examples would facilitate that.

Thanks

Michal

On 11/06/2020 13:52, Derrick Stolee wrote:

Is their also an option to also add an option to `git clone` to (re)set the default branch name offered by the upstream to that provided?

Alternatively provide a `--no-checkout` option for the clone so that either no actual checkout is performed, or maybe that a detached head checkout is performed so that users can name their default branch appropriately.

In some cases a true --no-checkout may be the 'best' thing to do to avoid the user mental model confusion about needing to have a local branch matching an upstream branch before they can start their work on top of it (hopefully with a fresh branch name).

Philip

On Fri, Jun 12, 2020 at 6:23 AM Philip Oakley <philipoakley@iee.email> wrote:

Good news: git clone already has a `--no-checkout` option (with `-n` being the short option form for it).

On 14/06/2020 01:41, Elijah Newren wrote:

Thanks. The man description "and creates and checks out an initial branch that is forked from the cloned repository’s currently active branch" had me initially fooled.

I did see the option after posting, but IIUC there is still the default branch name linkage that could be resolved.

Philip

There's nothing to be resolved because there is no problem. If someone reads "master" and gets triggered because all they can think of is racism, that person needs therapy.

1) There is a great deal of evidence that that claim is simply not true.
https://twitter.com/tobie/status/1270290278029631489
https://twitter.com/jpaulreed/status/1272064807345115137

2) It's beside the point. Many problematic words and phrases have
perfectly benign origins, but take on new meanings in new contexts.

I personally reject the kind of moral relativism that is being espoused here. In fact, I believe that there is such a thing as justice, and that we each have a responsibility to seek it out and create it in every corner of our activities, big and small. You can abdicate that responsibility, I can't force anyone to do otherwise nor would I want to. But history judges harshly those who would throw others aside. Of course there are more people in the world than just Americans. But there are also Americans, and in particular Black Americans. Precisely because git is the tool of choice for open source and so much other development work, I believe we have a responsibility to build a tool that reflects the values of _all_ that we want to welcome into these communities. If you would rather exclude Black Americans or others descended from generations of colonial slavery, that's your choice, but you need to own the fact that it is an inherently racist choice.

Don Goodman-Wilson

On Sun, Jun 14, 2020 at 2:20 PM Sérgio Augusto Vianna <sergio.a.vianna@gmail.com> wrote:

But YOU can force other people to engage in YOUR values and YOUR agenda? Why do you feel the need to coopt successful movements for a completely unrelated agenda? Free software achieved it's goal to protect people's software freedoms. If that's not enough for you, create a new movement and push a different agenda with it. Fork git, change w/e you want and leave normal people alone. I will repeat, only 8% of americans are progressive, you are a tiny, tiny minority. Just an incredibly vocal one.

Also, the reasoning that the word "master" excludes black americans is ludicrous. "Master" can mean so many things, then you CHOOSE to be offended because of one of it's meanings and now it's "INHERENTLY" racist and excludes people? Do colleges also exclude them when they offer you a MASTERS degree? Do chess excludes them because the highest rank is grandMASTER?

Listen to yourself, you are completely lost in pure, unadulterated ideology.

[apologies to those cc'd, thought I had plaintext on but obviously not so resending]

Hey, I got linked to this thread! Been following along since the beginning but only engaged on twitter so far.

To put the important stuff first: I believe the historical usage of the word is mostly irrelevant for understanding how a word is used today, and more importantly when deciding if we should continue using it. For this specific issue, I think if it's possible to have no default branch name (have the user name it when creating the repository) that is the best option; if there has to be a default branch name then let it be configurable and default to whatever the community wants to default to (which to date seems to be 'main').

On the history of how 'master' came to be used as the git default branch, and the history of how it has been used historically, there are a few things (and please note I do think this is irrelevant in the context of what the git default branch should be - this was originally a deep dive simply because I was interested).

First up, there are definitely usages from around the time git was created of the "Master and Slave" paradigm within the context of source control management, for example [0]. It seems like CVS also used the "Master and Slave" terminology when referencing repository management, but I haven't looked into that in particular [1] (the main branch is called trunk though).

The thing is, there are also a lot of usages that use the "Master Copy" paradigm, and when it comes to BitKeeper there are a lot more of this kind of usage than the "Master and Slave" usage. Perhaps the most authoritative I have found is the BitKeeper book, which says "shared master repository, private per user working repositories" [13].

The GNOME mailing list thread that is used as a starting point for this argument makes a lot of tenuous links, links I don't think hold up when looking at the full context. I'll try and address a few parts of this argument but again, this is just a bit of history I find interesting rather than an important consideration for changing git today.

Even if git borrowed 'master' from BitKeeper AND BitKeeper used it in a "Master and Slave" fashion, that doesn't mean that the person introducing it to git was using it in a "Master and Slave" fashion, nor that everyone else in git used it in a "Master and Slave" fashion. The best way to find that out would be to ask people who were there (for when it was introduced) and people who use it today (for how it has been used since then). Anecdotally, I have never seen anyone associate the master branch in git with anything except a "Master Copy" (or "Gold Master") EXCEPT when following that GNOME link [5]. I wasn't there at the time, so if anyone was would love to hear your input.

How likely is it that git borrowed the concept directly from BitKeeper, as opposed to some CVS usage or simply general usage? The first point made in the GNOME post is that 'master' was introduced with a CVS helper script [2]. Here is the snippet:

They then claim that this usage of master is

It's just as likely that the 'master' usage was common in the industry (for example, as stated in [0], which actually lends support for the "Master and Slave" usage in the industry), but let's go with it being copied from BitKeeper - what then was the usage in BitKeeper like?

The term 'master' is very common in the source and documentation of BitKeeper, but repositories are not explicitly named in BitKeeper so these usages are either referring to the machine the repository is on, a conceptual name in a workflow, or some non-repository related meaning.

For example @jpaulreed on twitter found a usage which is the "default config value for... what to call the repository displayed by the Bitkeeper HTTP server" [3]. You can see where it is used at [3.1]. (as an aside, a lot of that thread is showing usages of 'master repository' in BitKeeper, as opposed to "Master and Slave" usages, which I think is due to me not being clear about the point I was trying to make re "Master and Slave" vs "Master Copy").

The term 'slave' is somewhat common in BitKeepers source, though most usages are in the Tcl/Tk gui code so not relevant to this discussion. The ones that are relevant are talking about a slave machine (and the repository on that machine) as per [6], and a 'slave' comment in a test [6.1] (again found by @jpaulreed [4]).

In this HOWTO.ask file the terms 'master repository' and 'slave repository' are used quite a bit, but always in reference to the repositories sitting on the master and slave machines in the example. In other sections of this document, when talking about developers modifying the code, the terms 'Master' and 'WorkArea' are used instead. Indeed, as far as I can tell, all other usages of 'master' to refer to a repository in the docs are used in this way or are ambiguous about the usage.

Below I summarise all usages of 'master' in BitKeeper, apologies for the verbosity but I found it hard to do this on twitter, so I am listing them here (after my conclusion).

My conclusion?

Of all the usages of master in BitKeeper, the overwhelming majority of them are of the "Master Copy" variant, consistent with how I and many other people I have seen comment understand gits usage of the term master.

To reiterate my point at the top - I believe this information is irrelevant when deciding what git should do now, and my preference would be to have no default at all.

Examples that use the word slave:
- a repository on a slave machine (note the master-copy usage is also
used here) [5]
- a slave comment in t.automerge [6]

Examples that are consistent with a "Master Copy" usage of the word
master, and not a "Master and Slave" usage are:
- in the airgap docs [7] there are two masters, and 'Work Spaces' to
modify the code in them
- notes on binpool reference local and remote masters [8]
- bk-Howto-bkd has example code for cloning master to '~/my-tree' [9]
- quickstart docs has similar example to bk-Howto-bkd and additionally
talks about a master and a clone [10]
- the bam-pull test talks about a master and clone [11]
- bk-csetprune uses main as a synonym for master, and additionally
talks about cloning into 'src' and 'docs' repositories (splitting a
master repo into two) [12]
- the BitKeeper book, which says "shared master repository, private
per user working repositories" [13]
- trigger-master and trigger-copy repositories in t.resolve [14]
- in t.bam-clean, a master repository and its copy and a 'clean' clone [15]
- in t.bam2, a master and its clones [16]
- in-bk-config-etc "the location from which source can be cloned" [17]
- in t.checksum, cloning from a master to a 'client' repository [18]
- in bk-bkd, pushing from 'myrepo' to the master [19]
- in t.nested-attach, names used are 'project', 'copy', and 'master' [20]
- tag-master and tag-copy in t.csetprune [21]
- release notes for 4.x talking about multiple parents - local master
and remote master [22]
- in t.bam, tests referring to 'servmaster', 'someclient', and
'servmaster.copy' [23]
- in bkmsg.doc create a master repository for a package, then clone
into 'my_workarea' [24]

Other repository usages that talk about a master but are not
explicitly "master copy" or repository usage:
- bk-bkscc uses top-level as a synonym for master when talking about
Makefiles, and also talks about Master repositories but doesn't really
talk about relationships between repositories at all [25]
- event-stack propagation talks about master repositories, and appears
to imply a master-copy usage, but it's not clear [26]
- the 'Master repository' as listed in the webserver, no reference to
clones/copies/slaves or anything else [27]
- test for the webserver configvar master [28]
- when discussing rcloning, discusses multiple 'masters' but doesn't
really reference non-master repos [29]

Git related usages of master:
- in bk-fast-export [30]
- git usages in bk-fast-import [31]
- git usages in doGitExport.sh [32]
- in git2bk [33]
- in t.git-exporter [34]
- seems to be git related in fast-export.c [35]
- in release notes for 7.3.1ce introducing bk fast-export --standalone mode [36]

Other, non-repository usages:
- as discussed above, lots of Tcl/Tk gui code
- notes on DAEMON is a bit ambiguous, but no slave references or
implications [37]
- gnu patch talking about where the 'master source' for its code lives [38]
- crank.sh talking about a 'master template' [39]
- in bk-patch [40], gnu/patch/patch.man [41], and gnu/patch/pch.c
[42], references to an 'SC master' which are references to an SCSS
master
- release notes for 4.x referring to a 'master lease server'
(synonymous with authoritative) [43]
- in tomcrypt/DoxyFile references to "the master .chm file" [44]
- 'mastering' perl regular expressions [45]

Regards,

Andrew Ardill

[0] https://www.google.com/books/edition/Open_Sources_2_0/q9GnNrq3e5EC?hl=en&gbpv=1&pg=PA29 [1] https://twitter.com/hadessuk/status/1271487243950206978 [2] https://github.com/git/git/commit/3e91311ae750af9bf2e3517b1e701288ac3066b9 [3] https://twitter.com/jpaulreed/status/1272043692837072897 [3.1] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/bkd_http.c#L1264 [4] https://twitter.com/jpaulreed/status/1272042287732674560 [5] https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html

"master/slave" usages of master or slave [6] https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask#L223 [6.1] https://github.com/bitkeeper-scm/bitkeeper/blob/master/src/t/t.automerge#L90

"master-copy" usages of master [7] https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/airgap/airgap.gif [8] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/Notes/BINPOOL.adoc [9] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/man/man1/bk-Howto-bkd.1#L25 [10] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/doc/quickstart#L70 [11] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/t/t.bam-pull [12] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/man/man1/bk-csetprune.1#L94 [13] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/doc/book.ol#L14 [14] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/t/t.resolve#L909 [15] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/t/t.bam-clean#L31 [16] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/t/t.bam2 [17] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/man/man1/bk-config-etc.1#L105 [18] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/t/t.checksum#L241 [19] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/man/man1/bk-bkd.1#L240 [20] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/t/t.nested-attach#L611 [21] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/t/t.csetprune [22] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/RELEASE-NOTES-4.x#L917 [23] https://github.com/bitkeeper-scm/bitkeeper/blob/5695c0d0ecd062f13542c3cb04dd872466774fbf/src/t/t.bam#L360 [24] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/bkmsg.doc#L357

ambiguous usages of master [25] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/man/man1/bk-bkscc.hide [26] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/Notes/EVENT-STACK.adoc [27] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/bkd_http.c#L1264 [28] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/t/t.config-defaults [29] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/rclone.c#L158

git related usages of master [30] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/man/man1/bk-fast-export.1 [31] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/man/man1/bk-fast-import.1 [32] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/doGitExport.sh#L17 [33] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/contrib/git2bk.l#L35 [34] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/t/t.git-exporter#L50 [35] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/fast-export.c [36] https://github.com/bitkeeper-scm/bitkeeper/blob/5695c0d0ecd062f13542c3cb04dd872466774fbf/RELEASE-NOTES.md#bitkeeper-version-731ce-released-sep-29-2016

non-repository usages of master [37] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/Notes/DAEMON.adoc [38] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/gnu/patch/error.c [39] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/crank.sh#L16 [40] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/man/man1/bk-patch.1#L207 [41] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/gnu/patch/patch.man [42] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/gnu/patch/pch.c [43] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/RELEASE-NOTES-4.x#L980 [44] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/src/tomcrypt/Doxyfile#L639 [45] https://github.com/bitkeeper-scm/bitkeeper/blob/616740d0daad99530951e46ab48e577807cbbaf4/man/man1/bk-pcre.1#L146

Regards,

Andrew Ardill

On Mon, 15 Jun 2020 at 00:00, Don Goodman-Wilson <don@goodman-wilson.com> wrote:

Heya Andrew... turns out I read this list too, so... thanks for referencin' all my work!

Some thoughts inline:

On 15 Jun 2020 at 13:52:50, Andrew Ardill arranged the bits on my disk to say:

[SNIP]

https://marc.info/?l=git&m=111968031816936&w=2

https://marc.info/?l=git&m=111634468526506&w=2

Oops.

Do you have any specific references to, specifically, common usage in the industry, at that time?

See above.

Cool. Sounds like we mostly agree...

-p

Hi J. Paul, who would have thought! :)

On Mon, 15 Jun 2020 at 14:45, J. Paul Reed <preed@sigkill.com> wrote:

No problem, I appreciated the effort you went to.

This is an example we discussed on twitter, so I'll paraphrase/extend on what I said there.

This is definitely a "Master and Slave" usage by Linus, but is not an example of using "Master and Slave" terminology with respect to git branches. It is talking about mirroring kernel.org from a master to the mirror (slave).

It's evidence that Linus used "Master and Slave", but not (to my mind) evidence that the master branch in git was named master because of the "Master and Slave" meaning of master. It may have been, but this example doesn't seem like evidence for that.

I hadn't seen this one before, but this doesn't seem directly related to this issue either.

Linus says that "the public stuff [note - he is referring to master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git] is the _slave_. It has no meaning. The only important one is the one that the _developer_ works on."

He is saying that the public master is a slave to (as in a mirror that follows) his local repository. This is definitely "Master and Slave" usage (though an unusual one, as something called master is acting like a slave) but again it is not referring to how branches are named.

In that email, most of his usage is talking about "central repositories" or "main repositories", and "local repositories" which are referred to as workspaces; the only reference to slave is the behaviour of his public repository, in that it follows his local.

Nothing apart from those in my previous email - all of the BitKeeper references, and the book which does explicitly use the "Master and Slave" terminology - https://www.google.com/books/edition/Open_Sources_2_0/q9GnNrq3e5EC?hl=en&gbpv=1&pg=PA29

I wasn't focused on what general usage of master may have been, so didn't search out other examples, but the reason I think it's a reasonable alternative are all the usages from BitKeeper (some, such as the airgap example are very old, relatively) and the fact that so many developers today seem to think the usage is the "Master Copy" meaning (and assuming some level of continuity in language over the last 15 years).

In any case, this is not a strongly held belief of mine, my starting point was that most people (myself included) seem to assume the master default branch in git is the "Master Copy", and I haven't yet seen much evidence to suggest otherwise. Happy to see other evidence, and I'll go looking for some myself (in my obviously copious free time haha!)

Cool indeed :)

Regards,

Andrew Ardill

On Sun, Jun 14, 2020 at 03:58:33PM +0200, Don Goodman-Wilson wrote:

As far as I know using the word 'black' when referring to people is considered racist. Of course, it is completely benign word that might have taken on new meanings in new contexts. Last time I heard the 'politically correct' term was Afro-American. Of course, that might have also taken on new meanings in new contexts I am not aware of.

The kettle calling the pot black.

Of course, I have also seen patches to remove the occurences of 'black' referring to the constant rgb(0,0,0). The word can be considered racist in some circumstances so we have to remove all occurences in all contexts, right?

Fortunately the ones I am aware of are not accepted.

Thanks

Michal

On Sun, Jun 14, 2020 at 09:20:20AM -0300, Sérgio Augusto Vianna wrote:

Well, to be honest, if the software was written in German and used perfectly innocuous German words for "leader/worker" (fuhrer/arbeiter), I'm sure a lot more Europeans would get "triggered," as you say. We are not some kind of emotionless species, so historical connotations behind words do matter -- so it is not a "waste of effort" to have these discussions.

I support moving away from "master" for the default branch name -- and that is regardless of the negative connotations behind the word. Frankly, the word "master" is not very descriptive for the default branch name:

- most English-as-a-second-language speakers don't know the meaning of 
  "master copy," so even if we stick to this interpretation of the word 
  "master", then it's obscure and arbitrary to most new users of Git
- having a branch named "master" is already not required, so any 
  existing software that expects there to always be a "master" branch is 
  already broken and wouldn't get any more broken by the move away 
  towards more descriptive terminology
- as it stands, the "master" branch does not have any special meaning 
  anyway. It may or may not exist, and even if it exists, its contents 
  can be arbitrarily stale. You almost always have to check which branch 
  you want for your needs, so the implication of "master copy" is 
  largely meaningless in many workflows anyway.

Grosso modo, I see having a more descriptive branch name than "master" for the "default branch" as an improvement for the project in general. Making this configurable should assure full backwards compatibility to existing workflows.

-K

Ok, can you show me a single instance where "master" was confusing or not descriptive enough? Mind you, this all comes at the expense of a lot of friction in the LITERAL WHOLE WORLD. Bugs, stuff breaking, incompatibility issues, you name it. And let's not forget that people already have all the tools they need to NOT have a master branch if they don't want to. I think half dozen people can spare a few seconds instead of wasting literally everybody else's time fixing their respective software. Also, literally no one cared until americans went hysterical with the death of that guy in Minneapolis. It only shows it has never been an issue and is not an issue now. This is just 8% of americans trying to virtue signal at the expense of literally everyone else.

On Sun, Jun 14, 2020 at 03:23:29PM -0300, Sérgio Augusto Vianna wrote:

I just did. "Master" is not descriptive enough because it implies that a branch with this name carries some special status over all other branches, whereas in reality it doesn't. It can contain junk or be missing entirely. Therefore, having "master" as the default name is misleading.

Well, then nothing really changes then, does it? I don't see why you're so upset over a change that, as you say, will literally impact nothing.

Nobody should have to fix anything. If you already have an existing repository, then literally nothing changes for you. If you create a new repository and you don't like the new default branch name, it will take you no effort to change it to whatever naming convention you prefer. We are giving the community more choice instead of dictating the default.

False. Efforts to remove the usage of "master" traces back over half a decade, with many projects having done so many years back (Python, for example).

(I am deliberately ignoring your inciteful tone, but I would greatly appreciate if you don't use it again. I have all but run out of cringe.)

-K

 >I just did. "Master" is not descriptive enough because it implies that 
a branch with this name carries some special status over all other 
branches, whereas in reality it doesn't.

No, you presented a contrived explanation. I wanted to see a real word case where someone had issues understanding it.

 >Well, then nothing really changes then, does it?

Did you read what I said? I said it would be chaotic for everyone to deal with this change. It won't change anything for the people who WANT the change. They are just forcing everyone else to use what they want.

 >Nobody should have to fix anything. If you already have an existing 
repository, then literally nothing changes for you.

Except git flow. And any software that deals with new git repositories being created. The world doesn't revolve around you.

 >False. Efforts to remove the usage of "master" traces back over half a 
decade

There will always be people that adopt fringe ideologies. In the 1960 there were feminists that accused every single straight woman of being a gender traitor, for example. Yes, I said "literally no one", and that was hyperbole. I'm sorry if that went over your head so easily.

On Sun, Jun 14, 2020 at 04:08:53PM -0300, Sérgio Augusto Vianna wrote:

No, you "presented a contrived example," to use your own words. If you show me a "real word case" of how it would be "chaotic for everyone," then we can have a reasonable conversation.

Oh look, I'm all out of cringe now. I'm sorry, but I'm going to have to end it here.

-K

On 14/06/2020 19:23, Sérgio Augusto Vianna wrote:

Currently Git, and Git for Windows, both have an equal but different "master" branch with the same project root. Hopefully we won't have the same issue when the new default emerges [1].

Moving away for a centralised name in a distributed versioning system will offer the benefits of making the distinction between different forks of the same project.

At the same time the concept of a "master copy" is itself an oxymoron. Computer storage provides perfect reproduction at the bits and byte level, with strong verification through the hash values. My copy of hash X is identical to any other, and checkable via fsck. So we ought to be avoiding confusing terminology.

Philip

[1] Maybe the default can be called be anonymised to "ref0" <nycvar.QRO.7.76.6.2006131645380.56@tvgsbejvaqbjf.bet>

On Sun, 14 Jun 2020 at 20:24, Sérgio Augusto Vianna <sergio.a.vianna@gmail.com> wrote:

A: "No you need to fetch master from the remote, then you need to
merge it to your local master and then push it to the master master".
B: "remote master, local master and master master. wtf kind of master is that?"

Yves

On Tue, Jun 16, 2020 at 09:36:59AM +0200, demerphq wrote:

Which falls on the wording of the FAQ, not the terminology itself. If you were confused I am sure there are ways to bring this up and even submit changes.

Thanks

Michal

On Tue, 16 Jun 2020 at 09:43, Michal Suchánek <msuchanek@suse.de> wrote:

I think you missed my point entirely. Sergio asked how "master" might be confusing, and I gave an example where real people found it confusing. I have had the conversation I just outlined multiple times while teaching devs to use git on repos with "master" as the default branch. In fact at work we renamed "master" to "trunk" when we migrated our old CVS to git about a decade ago exactly to avoid this kind of confusion. Consider how this conversation goes for us:

A: "No you need to fetch trunk from the remote, then you need to merge
it to your local trunk and then push it to the master trunk".
B: "Ok."

Similarly when the perl project migrated to git we renamed "master" to "blead" to reduce the possibility "master master" confusion.

So I would say there is ample evidence that reasonable people consider the "master" branch name a bit confusing. Furthermore, claiming that the existence of a FAQ somehow makes this term not confusing is a bit strange, as I would say that if you need a FAQ to explain something it is not very obvious to start with so you are essentially proving my point for me.

Personally *I* have no problem understanding what the "master" branch is, I am pretty deeply familiar with how git works, I just think it is an inherently bad choice of default name for a distributed version control system for reasons entirely unrelated to it being also a term related to slavery. The latter to me just makes changing the default and/or providing easy ways to customize it all the better a move as ultimately it will produce less confusing and more inclusive software with little to no real cost to anyone else.

cheers, Yves

On Tue, Jun 16, 2020 at 10:01:54AM +0200, demerphq wrote:

No you did.

What I am trying to say is you did not your job well when the FAQ for git or your project has the answer "...and then push it to the master master".

Thanks

Michal

demerphq <demerphq@gmail.com> writes:

Hmph, why isn't the last one "trunk trunk"?

Or put it differently, "your local master? remote master? or the primary master?" would be a way to state the phrase A asked in the example without renaming the name for the primary branch to 'trunk'.

What I am trying to get at is, after changing the name that is given by default to the primary branch in a newly created repositories by "git init" to 'main' (which I am OK with, and it seems that the major projects and repository hosting services will be doing anyway with or without getting themselves in this discussion on this list), wouldn't we risk the same "master master" confusion caused by and to those newer users who learn 'main' is the word given to the primary thing?

Wouldn't you teach your users to fetch 'main' from the remote, merge it to the local 'main' and then push it to the 'main' main?

Hi,

Junio C Hamano wrote:

I think Yves's point is that when the tool you are building has a component named $FOO, it's confusing to also have a branch named $FOO.

So for example, if we were in the habit of calling main.c 'main' and frequently referring to it, this could be a reason to avoid also using 'main' as the name of the primary development branch. When someone says "that's fixed in main", it could prompt a moment of confusion --- did they mean that there's a fix in main.c, or that the fix has landed in the main branch?

In particular when building distributed systems, historically it has been common to have one of the components being built be named 'master'.

Fortunately in this context, I haven't heard 'main' used frequently that way. (I suppose it helps that main() functions are often short.)

Thanks, Jonathan

Jonathan Nieder wrote:

[...]

[...]

Of course I missed the other point --- hostnames like master.<domain> (e.g., a hypothetical master.kernel.org), refering to the source of truth for something that then gets replicated.

I don't think we're likely to see hostnames like main.kernel.org because it's just *so generic* as a word.

Jonathan

On Wed, 17 Jun 2020 at 22:17, Jonathan Nieder <jrnieder@gmail.com> wrote:

Yep, you summarized my point well. I would say master.kernel.org is a correct use of the term "master copy", and the use in the branch name is simply not. My "master branch" for git.git is NOT *the* master. It doesn't make sense to call something "master" and say it means "master copy" when there are actually multiple copies of the master. That isn't what "master copy" means.

So I would say that since in practice very often there will exist a repo which is considered to be *the* master copy of the repo having "master" as a default branch name is unhelpful.

And as you say "main" does not have this problem to quite the same extent. Although frankly I could see "main" being a common term in more distributed development processes where there might not be the same concept of a "master" repo, but there might be a "main" repo where people commonly share their work.

Ultimately if I was the decision maker here I would be choosing terms that are as workflow agnostic as I can find. "main", "master" and "primary" are not workflow agnostic, they are if anything a bit workflow opinionated. "trunk" on the other hand seems pretty self-descriptive and doesn't have much baggage. It's bark is worse than its byte however. :-)

cheers, Yves

On Thu, Jun 18, 2020 at 09:57:42AM +0200, demerphq wrote:

The most workflow agnostic name is "branch". it is so neutral that you want to change it ASAP :-).

On Thu, 18 Jun 2020 at 11:57, Oleg <lego_12239@rambler.ru> wrote:

I suppose I should have said "least confusing/ambiguous while most workflow agnostic". :-)

Yves

On Thu, Jun 18, 2020 at 09:57:42AM +0200, demerphq wrote:

This is actually an important philosophical point with software like git. There is no such thing as master.kernel.org for the very specific reason that we position kernel.org to be merely a convenient place where to get a *copy* of Linux. The "master copy" of the mainline tree exists only in once place -- on Linus's computer.

-K

On Wed, 17 Jun 2020 at 21:56, Junio C Hamano <gitster@pobox.com> wrote:

What I described was someone pulling from a box they have code on (which does not have access to the master repository) to the local repo on their laptop so they can push it to the master repo.

We have a master repo at $work. We use a mixture of centralized and decentralized dev models. To get your code into production it must hit the master repository, and it must be in the trunk branch in the master repository. I imagine this is a relatively common configuration, and problem in a professional context. Eg, I might be testing or debugging code on a node that is not allowed write access to the master repo for security reasons, so I need to pull the code from there to my local workstation and then push from there to the master repository. And all too often our people don't use topic branches for this stuff and just hack on their local copy of trunk. So from my point of view what I said was absolutely correct.

Well, "primary" is not a terrible replacement term for "master", but it isn't ideal either, as it also suggests the existence of a usable secondary, which isn't a correct mental model (for us). Personally I would eschew "primary" when there isn't a "secondary".

Yeah I think it will still cause problems. If it was my call I would not choose "main" either. Having said that I do think it is a bit better than "master" however, as it leaves the term "master" unambiguously about repositories, and it leaves the term "main" unambiguously about branches.

Also I would argue it is more etymologically correct. I would argue that the "master" branch in git terminology is NOT really the "master" unless it is in the "master" repository. "master" in the content of "master copy" implies "one" (it has to, what do you do if you have two masters and they aren't the same!), but using it in a distributed sense for a branch name doesn't imply one, it implies many, so it really doesn't make a lot of sense.

Unfortunately we call our main repo "main.git", so for my workplace "main" as a default branch name would be suboptimal. We chose "trunk" because "main", "master", "primary" all have these double meanings. On the other hand "trunk" is the standard word for the things that branches grow out of, and in some trees, the branches even can merge back into the trunk![1] Thus I find it weird it isn't perceived as the "obvious" choice to solve this problem. That the bulk of the population chose "main" suggests to me a lack of imagination more than a reasoned and thought through decision.

Anyway, personally I would say "main" and "master" are both bad choices for the default *branch* in a tool that is as workflow agnostic as git is and seems to intend to be. It is relatively unfriendly to scenarios where there is in fact a "main repo" or "master repo" . Many people will in practice use git in a relatively centralized way with at least one repo designated the "main" or "master" repo for the project, and so you end up with two "master" or two "main" things that are very different with very different properties.

So yeah, I would say that "main" is slightly better than "master" but is still suboptimal from a comprehension point of view, and it is downright unhelpful for my $workplace (but I recognize that isn't a problem you should be considering in this discussion.)

Thank you for your time and efforts in dealing with this subject.

cheers, Yves [1] https://www.reddit.com/r/mildlyinteresting/comments/25xkg2/a_tree_branch_grows_back_into_the_tree/

demerphq <demerphq@gmail.com> writes:

Well, 'main' is clearly better than 'master' as there do not seem to be so many haters of the former than the latter.

But you cannot escape from the fact that when you need to have one special/primary repository among different ones, and each repository has one special/primary branch among different branches (and you are lucky that you have to only worry about two levels in this case), it is inevitable that you risk the "master master" problem no matter what, unless you choose different word for 'primary' at each level.

It may be that it is the default _branch_ name people are unhappy about the use of word 'master', but I do not see the reason why people would not be unhappy about your reference to the 'master' repository of a project the same way. So basing your argument to rename the default _branch_ to 'main' (or any word that is not 'master') because of "master master" problem does not compute well, which was my point. 'main' is not better than 'master' because you want to keep using 'master' to refer to your primary repository.

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

The above is mostly true but not entirely, I have to remind you.

There certainly is the concept of the primary branch in each repository. With the current version of Git, it is hardcoded to be the 'master' branch, and we are going to make it configurable with a configuration variable [*1*]. There are a few examples that the primary branch is treated specially:

 - When merging into the primary branch, the auto-generated merge
   message is different from a merge into any other branches.  This
   was because most of the merges, especially in early days of Git,
   were into the primary branch (there weren't many cross-branch
   merges made) and we did not want to see repeated "Merge X into
   'master'", "Merge Y into 'master'", etc.---we just say "Merge X",
   "Merge Y", etc. when merging into the primary branch.

 - "gitk" gives preferencial treatment to 'master' when there are
   too many references it has to choose which ones to make visible.

 - "git fast-export --anonymize" redacts the name of all the
   branches, but the name of the 'master' branch is left intact in
   its anonymized output (which is done in order to make the primary
   line of work identifiable even in the redacted output stream).

There may be others. Software that assumes that 'master' is special is *not* broken as you stated (we will break them when we allow changing the default---that is the cost those of us who are working on the transition plan thought worth paying). The concept of "there is one thing that is special among others" can serve useful purpose.

It of course opens a different can of worms ;-) Even though we can please master-slave-haters by moving away from the particular word 'master', those who cannot stand the very idea of one thing being special among others will not be satisfied (and we shouldn't even try to please them, IMO).

[Footnote]

*1* There is a related but separate concept of the "default name" for the primary branch in newly created repositories, which also is hardcoded to be 'master'. We are going to make it configurable, too. This controls the name used by "git init" (possibly we will also add a command line override "git init -b name" to countermand the configured default) and "git clone" (which tries to use the name of the branch pointed at by HEAD of the other side but has to fall back to something when it cannot figure it out).

Junio C Hamano <gitster@pobox.com> wrote:

As somebody who does not like the idea of things being special, I'm considering renaming "master" of the few projects I maintain to "unofficial". It fits my anti-centralization and anti-authoritarian mind, at least :>

Eric Wong <normalperson@yhbt.net> writes:

We probably can teach "fmt-merge-msg" (which is what helps "git merge" to special case the message for merges into the primary branch) and "fast-export --anonymize" to honor some special value for the configuration variable (core.primaryBranchName???) so that they treat that NO branch is primary/special.

Perhaps an empty string would serve the purpose.

Sérgio Augusto Vianna wrote:

Please stop.

Regardless of your opinions, this is not acceptable conduct on the list. It is perfectly possible to describe your needs as a user and your opinions about best technical courses of action without insulting people.

It's also not particularly effective. There's a clear consensus already among active Git contributors that changing the default branch name is a problem worth solving, and there's active work being done in that area. You are free to roll back these patches in your own local copy of git, but repeatedly asserting that *you* don't value this work is not a particularly productive way to participate in the Git project.

Jonathan

Yes, half dozen people who are scared to be cancelled agreed with it. Tell me what, why don't we run a poll on popular places about tech and see what people think of it? It's pretty authoritarian to force the whole world to be affected by a change that only very few want. There's barely a dozen people in this conversation for a tool that is pretty much a global standard.

Thanks Johannes and Don for your work on the patch! And Billy for sharing your investigations and thoughts on naming.

Yes, we are investigating the changes needed to support changing the default branch name of new projects created in GitLab.

Great idea - thanks Emily! Please include me in the invitation.

Hi,

On Wed, Jun 10, 2020 at 2:34 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Looks like they've done some good research; I'm glad someone has looked into it.

It probably doesn't matter at this point, but can I point out an additional issue with "default"? I worry it's quite likely to lead to confusion: does "default branch" mean the one named "default" or the one HEAD points to? For example, at $DAYJOB, hundreds of repos switched a few years ago to having "develop" be the default branch, but did not delete "master". Had the default branch been named "default", we would have been in a funny situation where "default" was not the default.

You may just think that's a humorous case, but it's more than that to me. Once upon a time in the Gnome community we had a theme called "default" that many people thought was rather ugly; a new theme was created with a different name that became the default, but for backward compatibility the old one had to retain the name "default". Soon there were lots of themes and almost no one directly used either of these two, but the release notes were required to use the default theme for screenshots (that is, the default theme, not the "default" theme). Anyway, wires got crossed and there were some massive, heated, protracted flame wars that engulfed way too many people (see https://blogs.gnome.org/newren/2005/03/15/poor-eugenia/). While the reaction there was blown way out of proportion (the flame wars really were unnecessary and having a code of conduct in place might have helped prevent some of that rather poor behavior on both sides -- myself included), there was a nasty problem that arose from a simple communication disconnect that was real. It could have all been avoided if "default theme" wasn't ambiguous and for the same reason, I don't want "default branch" to be ambiguous. Although I wasn't directly on either side of the Gnome fiasco and was just one of many that got pulled in as the whole project got dragged into the whirlpool of problems, I really don't want to be involved in a repeat of problems of the sort "oh! there's another default branch?!?"

Hope that helps, Elijah

A quick clarification:

On Mon, Jun 15, 2020 at 2:38 PM Elijah Newren <newren@gmail.com> wrote:

...or the one HEAD *on the central server* points to? (This issue may not be relevant to those that aren't operating with a central repository workflow, but the branch checked out when the user first clones is often thought of as the "default branch".)

From: zeevriend@gmail.com

First I want to thank you for the time. I think the change is good and discussion about inclusive really necessary. Let me tell you I have Congolese ancestry. Today I develop in Brussels, Belgium - the irony you see, is not :-) Second let me tell you the new master name 'main' is not so good chosen. In french 'main' LITERALLY means 'hand'. The recent history in Congo will explain why this is bad. Not long ago slaves in Congo because of Belgian rulers. Very sad history, because hands were cut off! Many Africans today still have family from then. My grandparents can tell me horrible stories when I visit :-( I think you can see now why 'hand' or 'main' is very offensive to us. I can tell you, for French Africans this is MORE offensive than 'master'! Because this reason, we do not want to be reminded of hands while using git. Third I can suggest 2 more neutral alternatives. First one is 'default', which has almost same meaning in French. Second alternative is 'zero' or 'branch0'. I like this one more, because it has an exact same meaning in French! Also it is very neutral and programmers from all the world can agree on this, we all start counting at 0! ;-)

Thanks for the time and considerations! And excuse for the level of English. I hope you have good days next, healthy and stay to fight for the good causes!

On Tue, Jun 16, 2020 at 11:07:01PM +0200, ZeeVriend wrote:

No-no. Please. "branch" is sounds bad for cyrillic hear and has bad associations. Like a "брань". "zero" is like a "nothing" or "looser".

From: Zee Vriend <zeevriend@gmail.com>

Dear Oleg,

Thanks for your feedback. I have no knowledge from cyrillic so it is nice to hear from you! As a fact, in French "zero" also has bad meanings. But, positive meaning exist also. Building up from nothing as example I give you. Now if my suggestions are not ok we can try something else. I thought alternatives can be "source" and "root". Both are used A LOT by programmers everywhere so possible they all agree! Let me tell you "source" has EXACT same meaning in French, I like it a lot. We all write 'source code' is not? Maybe you have other words to describe this. We can all share the best words and select the best agreement. A true inclusive collaboration from all! Let me wish you a good day and happy moments next!

On Wed, Jun 17, 2020 at 10:48:42PM +0200, ZeeVriend wrote:

A positive meaning exist for any word ;-).

Not all of us :-). Somebody try to play in politics games, instead of coding.

Yes, i have one - "master". It's used about 15 years by millions of developers and projects. I think this is a best portfolio ever. Other words we are discussing already show drawbacks. We have no one ideal word :-). In any case, this is not matter. Nor my or you opinion. There are some white people with conscience problems and they try to solve it in such a strange way. After that, they willn't become better, but they think they will. Code and the rest of humanity just victims in this situation.

Thanks. But i don't see any happy moments here.

From: Zee Vriend <zeevriend@gmail.com>

Dear Oleg,

Thanks for your feedback. I have no knowledge from cyrillic so it is nice to hear from you! As a fact, in French "zero" also has bad meanings. But, positive meaning exist also. Building up from nothing as example I give you. Now if my suggestions are not ok we can try something else. I thought alternatives can be "source" and "root". Both are used A LOT by programmers everywhere so possible they all agree! Let me tell you "source" has EXACT same meaning in French, I like it a lot. We all write 'source code' is not? Maybe you have other words to describe this. We can all share the best words and select the best agreement. A true inclusive collaboration from all! Let me wish you a good day and happy moments next!

There will always someone that will take offense to literally anything. It's absurd to try and sanitize everything with fear that someone, somewhere, someday will just get offended by something.

The perpetually offended strikes again. It's very problematic to let people police other's language. This is something literally out of 1984.

On Mon, 4 May 2020 at 18:22, Simon Pieters <simon@bocoup.com> wrote:

Hi Simon,

Definitely agree, and thanks for starting this.

One question that's been rattling round my mind is how we change the documentation to suit. By that, I mean, it has become common parlance at the moment to say "master" as the canonical branch, because that's the one that's been baked as the default. Now that we're making this configurable, I'm curious how we're going to change our semantics to match the "default" branch (which was "master") when talking about git branches, either here on the list, or in documentation.

Kindly, Thomas

Btw. The default branch, if it must have a new default label - how about calling it “default”?

Sent from my iPhone

You say this “master” has anything to do with slavery? Then be more explicit and true to history, and instead of master call it white. Sorted! If not please stop this nonsense thanks.

Hi Michael,

On Sun, 14 Jun 2020, Michael Felt (aixtools) wrote:

This has been considered. In fact, I originally worked on the patches under the assumption that "default" would make for a good term here. However, there are a couple of arguments against it that I found convincing:

- There are actually two concepts at play here: the actual main branch in
  a concrete repository, and the default name we use for that branch when
  initializing a new repository. In this mail thread, we are talking about
  the latter. It does sound needlessly confusing when you spell out "the
  default name of the default branch", which at least to me is a good
  indicator that there must be a better term to choose.

- While it is true that we are talking about the branch that is checked out
  during a `git clone` by default, it is definitely not the default branch
  name for your development in many flows: Typically when starting some
  new work, your default is _not_ to work on the main branch, but to
  branch off new topic branch.

- Imagine you are in serious financial trouble and have to see the word
  "default" every day. It might not seem like a very convincing argument to
  those among us who are far away from such financial troubles, although
  for the less fortunate, we would create yet another source of distress.

My current working hypothesis is that `main` would make for the best term to use. Let me offer a couple arguments why that is.

- It seems to describe best what this branch is about. It's not anybody's
  default to develop on this branch; Instead, it is where the main part of
  the work eventually lands (just like in the "main branch" of a company).

- The name "main" is short and sweet.

- It might sound silly, but muscle memory is a thing. And ma<TAB> will still
  work with main. I bring this up because I would not have expected this to
  matter in practice, but my personal experience of the last few days
  contradicts that expectation.

- Looking at my Twitter feed, I see a trend toward using "main".

Ciao, Johannes

Hi Thomas,

On Sun, 14 Jun 2020, Thomas Adam wrote:

This has been on my mind, too. It is a big reason why I keep mullin over the naming, like, a lot.

In my mind, it will be helpful for people updating documentation out there to use terminology that was chosen with care. My current thinking is that "main branch" is the best description of what the construct is about, and "the default name of the main branch" is what we want to change.

Ciao, Johannes

I'm just posting it here because apparently the guy posted but it wasn't included here? I don't know.

"Michael Felt aixtools@felt.demon.nl

How does the saying go...

You can please some of the people all of the time,  ..., but you cannot please all of the people all of the time.

I learned as a child that my choice of certain words was influenced by words used by people i trusted. Words that I clearly did not understand completely because when I (tried) to use them, with no negative intention, but saw the use of a word shocked the people who heard me.

Does that mean I was a racist, or am a racist, because I used a word that others considered racist. Yes, I was naive. But I learned words can offend, regardless of intent.

And I feel that is what is missing here. Using a term that someone else takes offense to does not mean any offense was ever intended. But I tire of hearing that I am responsible for knowing what offends “them”. And since I am one of the unlucky, not clearly belonging to a “minority “ of some kind, I may never complain.

But I was well above 40, and learning from my own children,  before I learned to deal with all the persecution i had to live through in my early years.

Racism is a powerful word, and it exists everywhere. Sometimes it is intentional - and we need to address that. But do not make the mistake that it is always intentional.

A git “master” or “main” - who really cares. Do not seek offence where none is intended. You only make your own life miserable.

Compare that with teasing (not as horrible as racism it seems). Just remember, teasing is always intentional, the object and objective of teasing is always clear.

The intent of a word choice is not always how it is received.

If “master” offends you, I feel for you. If “main” makes you happy, I am happy for you.

I am saddened that people feel that “master” in git is an expression of racism. It is not. I am saddened that people feel it must be changed because someone takes offense.

I also know my opinion does not matter. The fear of the many becomes the “ring that rules them all”. "

Someone sent me these points for me to use in this discussion. But to be fair, I'm kind of done so I will just paste what he sent me directly:

Don Goodman-Wilson said:

 > My feelings generally are: if you have to explain why it isn’t
 > racist, then there’s probably a better alternative.

Now this is already problematic as there is the idea of reversing the burden of proof: he shouldn't point out that you have to explain why it isn't racist, instead he should explain and prove himself that it's racist and offensive, since he's the one making that claim and asking for change in the first place.

All the sources I've seen linked in the thread are either Wikipedia, that anyone can edit, or Twitter, where anyone can post anything, or unspecified and unverifiable anecdotal evidence of the type "I've seen people getting offended by it." This is not okay.

Perhaps the best argument you could make is that if and before changing the name "master", there needs to be measurable proof of how many and how much people are actually offended by the use of "master", and an assessment of how many people would be offended by other proposed terms or by the new chosen name, and a measurable assessment that changing the name would actually reduce the amount of offended people, and have a positive impact worth the effort.

In software development, people often say that if you can't measure that your change in the code actually makes a difference and has an impact going in the right direction, then you shouldn't bother writing that code to begin with.

It seems the developers made their mind, so I'll just leave some food for tought.

https://www.youtube.com/watch?v=KEU-t-ANpdY

It seems the developers made their mind, so I'll just leave some food for thought.

https://www.youtube.com/watch?v=KEU-t-ANpdY

By the way, I just found out about this issue:

https://github.com/git-for-windows/git/issues/2674

76 upvotes against 490 downvotes and that's because it was shut down. If that's anything to go by, this proposal is WILDLY unpopular. Unless anyone has any other metric, going through with it seems that will disregard what the actual users want by a great, great margin and be just what I said earlier: an authoritarian display of power.

From: "Fang-Pen Lin" <hello@fangpenlin.com>

Actually, I saw many blak people claimed they think this renaming "master" to "main" branch movement very offensive or even racist. Like this:

Quote:

https://twitter.com/Speedkicks/status/1272291128000167937

I am not a black person, but I also found this movement to be very offensive. As a person grew up in a country used to have language and thought policing, i.e. people could end up in jail or even got killed because they say something. In that environment, you are taught not to say any opinion at all even it has totally nothing to do with the sensitive topics, like the leader of the country. Sometime it could just because this word sounds like that, people could interpret the way they like it to be, report you to the government and you will disappear very soon. I found this renaming movement pretty much like that.

I'd like to bring the opinion of someone that's black in this issue:

https://twitter.com/Speedkicks/status/1272283853617459200

 >Reading a thread of white people, including the CEO of GitHub, 
advocating changing the name of the "Master" branch to make black devs 
more comfortable... is the most racially uncomfortable I've ever felt 
about GitHub.

https://twitter.com/Speedkicks/status/1272291128000167937
 >Reasoning: Living as a black person is not to constantly remember how 
different you are but how different other people believe you are and how 
that changes your experience.

 >Now I can't even say "push to master" w/o the paranoia everyone around 
me's thinking about me being black.
So congratulations, white saviors, you just made things awkward for 
actual black people in the community. You keep treating minorities as if 
they are children. You don't actually respect them. You don't actually 
listen to them. This is what you do, you just create a greater divide. 
You just single them out.

From: lkcl@lkcl.net

simon,

sadly i regret to inform you that both the subject line that you've used, and the assertion that you make - that "master" is automatically an inherently offensive term - is what a lawyer would call "leading the witness". it is a false correlation and unfortunately nobody has picked up on this in a significant way.

it would have been far better and much less problematic not to have made any false language-based assumptions as the *fundamental basis* for this entire conversation, by using, for example, the following neutral and objective words:

    "some people may believe that there is an implication - false or
    otherwise - that the use of the word master in git implies a
    corresponding association with slavery.  whilst i appreciate that
    this is a technical list, in light of today's current social
    climate i would welcome open and honest discussion on this subject"

do you see the difference? instead of indicating that you respect that this is a technical list, and *invite* people to discuss it, you opened with a *demand*, backed up by not one but *two* false correlative assertions: one in the subject and the second in the opening sentence, which has proven difficult for people to unpack.

i notice also in follow-ups that you also use similar language and make similar assumptions, which _are_ picked up on and found to themselves be *offensive by readers*. in light of the topic being to change the use of an offensive word, this is highly ironic! (i am delighted to then see that you apologised and indicate that this was in no way intentional).

my observation is however that you have a pattern of this type of false-correlative language usage that you may wish to examine more closely, in order to not mislead or offend others. do not think that you are alone in this! we all do it, myself included, unintentionally. our strength of character is in how we react when it is *pointed out* to us our mistakes, and it is a hugely positive sign to see that you are well-intended and wish not to cause offense to others.

we have also engaged in a discussion on our list, provided some insights into this topic. as an ethical technology advocate with a responsibility and a duty to consider the full implications of the use of my skill, i have been thinking about this "political movement" to change the landscape of engineering terminology for some years.

summary: it's not a good sign.

interestingly, one of our team members opened the discussion with a similarly loaded question: http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-June/008259.html

    "should we avoid the association with slavery?"

which is again a highly loaded / charged / false-correlative question (that i immediately picked up on).

the first follow-up simply pointed out that there are a huge number of alternative overload meanings for the word "master": http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-June/008263.html

    Record-master
    Film-master
    Tape-master
    Digital-master

    Master (as in teacher)

followups on this include document management commonly-used phrases:

    Master copy
    Master document
    Master Bill of Materials

do you notice that *at no time* is there *any* association in any one's mind with "slavery"? nobody gets offended in Eastern countries when they meet a "Master"! it is a word of *deep* respect!

another follow-up goes into detail about the critical importance of the use of the words "master" and "slave" from an engineering perspective (we are implementing a processor: the Wishbone Specification for example *has* to use the terms) as well as providing further insights: http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-June/008264.html

    the engineering meaning of master and slave is as follows:

    * master specifies unequivocably the action required.  this is
      an atomic contract

    * slave carries out that action unequivocably and atomically.

    in other words it is an atomically guaranteed 100 percent
    inviolate and 100% accurate transferrance of *information* from
    one source to another.

    any violation of that contract has such severe consequences in
    engineering (catastrophic data loss in the case of git, and loss
    of life in the case of mission critical real time control systems)
    that to consider anything other than this type of contract is
    unthinkable and flat-out impractical.

this reply also points out that the current motivation for changing the meaning of the word is, sadly, for the purposes of "Social Justice" that have at their heart a guilt-ridden desire to forget history by eradicating words from common usage, with complete disregard for the fact that the word has multiple meanings. the "if you're not with us you're against us" false-correlative argument that has caused untold misery and strife throughout human history.

this then led another of our team, who has a degree in Liberal Studies and Literature, specialising in the study of slavery, to write about the dismaying ongoing inversion and distortion of ethical and liberal movements: http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-June/008277.html

he points out in particular that the current "Social Justice" movement has all the hallmarks of a modern-day religion!

https://newdiscourses.com/2020/06/postmodern-religion-faith-social-justice/

so i leave that with you to consider, and the observation that i am witnessing a huge amount of guilt and deep-seated unease over this topic, which is perfectly understandable and we - all of us - need to feel comfortable being able to express that unease in a public way (being part of an open movement after all), and to feel that we are being heard and respected.

yet... at the same time recognising that this is *engineering terminology*, for which, due to ongoing legacy usage, a substitute word would cause far more harm than allowing the continuing use of that word. further, that in an *engineering context* and in other contexts, that word simply does not have or cause offense in any way except in the minds of those who - and this is a whole new subject - *choose to be victims*, and in some contexts its usage is a deep and fundamental sign of respect!

in short: i invite everyone here to consider whether to choose to "react" to the Social Justice Movement / Religion - (become mired and victimised by it), and instead to focus on continuing to apply their superb engineering skills to develop technically excellent code, whilst at the same time remembering at all times to be deeply respectful and conscious of the fact that people *are* going to raise these and many other Social Justice style topics on public technical mailing lists, and to give such people the space they need whilst also reminding them of the core goals of the project on which they have brought up that Social Justice topic.

respectfully,

l.

First of all, I offer my excuses for inserting myself into this discussion as an outsider. It will probably seem a little laughable or sad that someone would feel the need to do that just to vent their frustrations outside the public social media platforms. However, I want to add mainly one thing, that has been completely absent from discussions elsewhere (it has been hinted here, recently).

First, I will state my position, so that the actual argument can be put into the context of where I'm coming from (or maybe just because I wanted to vent some more...)

- Giving users an option is a good thing.
- Solid conventions that are rarely overridden is also a good thing.
- Moving away from "master" may be the right thing to do, but there
are certain ramifications (also optical) to such things, so the
reasoning should be informed.
- "Tagging" certain words as offensive or non-inclusive can be a
disservice to a working, sensible, constructive, emotional,
informational and nuanced language. At least when said word, in its
context, is used completely without its possible negative
connotations. It creates an emotion and a problem where there was
none.
- The actual origin of the word in git is irrelevant. How it's used is
what matters.
- The "perpetually offended" may be a moniker that's a bit too lazy.
But I would argue that there is at least a large group that could be
called the "eager to be offended, by proxy"

So, my argument.

Why is no-one talking or listening (!) to those who are assumed to be offended or hurt? That may be a false assumption, but it's certainly how it seems. I can only speak from my limited viewpoint, and for the sake of argument, let's say that we're talking about black people, or to narrow it down, black software developers. Is that too exclusive? Well, maybe, but it's the scope I'm using now, and I think my argument would remain unless we include the not-assumed-to-be-affected-but-still-uncomfortable.

I tried to get an idea of how the GitHub move was actually received by black developers (I'm white, by the way), by googling and searching on Facebook and Twitter. And I really didn’t taint my searches with my bias (e.g “black developer github master”). The impression I came away with was that 100% would rank the move somewhere between unnecessary, via laughable, to downright offensive. The move. Not the word. The voices I found are not necessarily representative, but they should at least give some pause. A common reaction seems to be something like what @SpeedKicks (a software engineer in the "target group") tweeted:

"Reading a thread of white people, including the CEO of GitHub, advocating changing the name of the ‘Master’ branch to make black devs more comfortable...

is the most racially uncomfortable I've ever felt about GitHub."

Acting on the uninformed assumption about someone else's feelings can be very counter-productive, belittling and even racist.

This leads to my last bullet points.

- Staying with the word "master" can if motivated properly (or not at
all, since it seems to be a reaction to an ambient issue), be an
action that is even more grown-up, respectful and therefore inclusive,
than moving away from it.
- Can someone still be offended? Sure, but I think the solution to
educate, rather than eradicate, should be used more often.

Best regards Gunnar

Den mån 4 maj 2020 kl 19:20 skrev Simon Pieters <simon@bocoup.com>:

Excellent post but I think your post also missed one other possible downside. Excluding developers afraid of politics becoming more important than technical development in projects just as many developers did and left python after their change.

On Wed, Jun 24, 2020 at 01:21:32AM +0200, Gunnar Liljas wrote:

Yes. That's sad. This is the real problem. Devs of some projects, whether they understand this or not, work as provocateurs and incite hatred between people. Their actions hurt black people. After that, black people will feel that almost everyone hates them(because it was done "for them"). But i don't think devs are so evil. They are just computer nerds/geeks and complete idiots in social sphere. They don't understand the consequences of their actions and just a toy in politics game.

On Wed, Jun 24, 2020 at 10:19 AM <lego_12239@rambler.ru> wrote:

I don't think many would feel that. More like that everyone ignores them and their opinions. But that's just the thing, I can't and shouldn't presume to know what others are thinking and feeling. If an action is to be taken, I should at the very least do my best to acquire this knowledge.

/Gunnar

On Fri, Jun 26, 2020 at 12:08:30PM +0200, Gunnar Liljas wrote:

Almost all of adequate people. What else they should think? In situation where devs, instead of stay away from hype, say to millions: "we will broke program you use, because of them". And every adequate people understand that this is stupid action(any man with any skin color), but only black people is the declared "cause" of this actions. Naturally, they do not feel comfortable.

 >But the people that contribute to the code and to an open-source 
project are the owner of that project so they get to get the calls.

Ignoring everyone else's opinions and needs and just exerting your authority is the very definition of authoritarianism. Yes, they do have the right. But if they ignore the users, they can just use a fork that does what they want. Have anyone considered that a breaking change in git might very well result in a fork?

Sérgio On Mon, Jun 15, 2020 at 10:37 PM Sérgio Augusto Vianna <sergio.a.vianna@gmail.com> wrote:

Well... fork happens sometimes when two groups of people completely disagree and cannot work together. I really hope a vote here would be enough to settle things.

Sérgio, I'm actually with you on this side, just to state my opinion as well.

I haven't yet heard of a person that is offended by git master branch. I've heard thou about persons that think that some others will get offended. But most of the time, I've heard about people that think this world got crazy on git master branch naming :).

But I guess you've heard that already from other participants already, so I apologize for repeating it.

And I believe that both of you, Sérgio and Jonathan, were a bit rude to each other :) Let's relax and have a drink! Cheers!

Alex

On Mon, Jun 15, 2020 at 12:51 PM Alexandru Pătrănescu <drealecs@gmail.com> wrote:

Calling out violations of the code of conduct certainly takes some directness, but merely calling out the behavioral violations is not in and of itself rude. Sérgio's behavior I think is exactly the type of reason we adopted the code of conduct; insulting others is not wanted and is not welcome on this list. The harder part of having a code of conduct is trying to coax people to follow it. Several folks tried nicer responses to Sérgio earlier in the thread, but to no avail. From my view, a more direct response was clearer needed. I'm grateful Jonathan jumped in to do so; I thought he did an exemplary job.

Elijah

On June 15, 2020 3:38 PM, Sérgio Augusto Vianna wrote:

Without seeing the whole context of this response, I will answer simply as a repository manager, not a platform maintainer.

While I fully understand the requirement to change the term "master" (and I think it should be changed), the situation must be put in the context of the available technology. In all major players, whether git itself, or GitHub, BitBucket, GitLab, or AzureGit (there are probably others, but I'm trying to cover 95%-ish), the repository manager/owner has the freedom TODAY to change the default branch to anything they want, within the limits of the character set encoding and name contents. No change in code is required to make this change in one of your repositories. Action is required, some configuration, but it is not a difficult or lengthy activity, to change the default behaviour.

As happened with Jenkins as an example, I expect that the community will handle this change over time as is practical to cover all the (previously mentioned hundreds of) touch points without braking the one DVCS that manages much of the current set of production operating system code (a.k.a. git).

My team still has a just few legacy repositories that still publish "master" as the main branch because if the impact on our deployment infrastructure - which is critically customer facing. We will address them when we can do that without impacting customers. But we are standardizing to a more GitFlow approach with "development" and "release" as our main branches and "bugfix/*" and "feature/*" as topic branches - with "development" published as the main branch. That is our choice. You can do something similar as technology stands today in the git ecosystem.

I cannot comment on OpenSource or commercial git clients who might have limits on their own naming standards, but the bulk of them should be agnostic to the published default name. However, scripts that use git (and there are a huge number of those) should also respect the default branch as published without hard-coding the term "master" to allow us repository managers to seamlessly change what we publish for our communities (yes, I am guilty of not following my own advice today looking back historically because I did not know better some 8 years ago).

With Respect, Randall

Not just that, any twitter use can complain and get entire communities to throw out all rules on changes to appear to be on the "right" side. If anyone submitted a patch to change any functioning name without good reason, especially one assumed to never change and would likely break a significant number of external processes it would be denied without second thought. Here the entire thread didn't ask should we change it but instead started on the premise, even though this is documented throughout the world and millions or even billions of scripts and programs assume it to be constant, it must change without discussion.

Not just that the entire process has become a laughing stock that the tech community seriously believes anyone has a problem with 'master' but even worse that it will somehow fix something in the world. You can find no shortages of post on forums and websites of people wondering what exactly is trying to be accomplished.While not done here presumably due to being more difficult to access, every other venue of commenting has been either ignored (e.g. twitter) or closed to discussion under the premise its becoming to aggressive to argue against. This thread is not much better quickly coming to a decision that its not IF it should change but WHAT it should change to.

What reason could possibly be good enough to break backward compatibility with itself, break assumed standards of interaction with the software, and all without major review process? I have seen critical security patches with more insight than how quickly this word change is being pushed through both here and other locations.

On Tue, Jun 16, 2020 at 07:38:33AM -0400, Whinis wrote:

Some people don't think about it. They not engeeners, they are linguistic racist. May be it time to fork git... and place it somewhere where people are better educated, more democratic and not so totalitarian to words.

I'll tell you more. On almost every non-english forum you can see that users wonder about this incredibly stupid process :-). And you are right. Anywhere in the world, outside US, this looks like a laughing stock :-). All people just sit near their monitors with popcorn and looking what else crazy white americans will do with all production stuff to which they have access.

Actually, it's sad like any obscurantism.

On Tue, Jun 16, 2020 at 07:38:33AM -0400, Whinis wrote:

Let's leave emotionally charged rhetoric and discuss this like reasonable human beings.

Here are facts:

1. Git is distributed software. It's not a central service and it does 
   not manage any code hosting platforms. It has no control over what 
   Github, Gitlab, whatnot or other decide to do. If you don't like what 
   they are doing, take it up with them and keep it off this list.

2. Branch naming is entirely the choice of individual repository 
   maintainers. Some prefer not to have a "master" branch, and it's not 
   simply because of "political correctness" reasons as everyone 
   insists:
   
   - they may prefer to have "stable" and "development" branches
   - they may want to use localized names for all their naming 
     conventions (using Cyrillic, Hanzi, Kana, whatever)
   - they may be goofing off (there's a furry-related repository on 
     GitHub with the main branch called "yiffed")

3. In your example, "millions and billions" of scripts are already wrong 
   if they assume that there is always a "master" branch. However, it 
   doesn't matter, because unless someone actively renames a branch in 
   an existing repo that they work with, they will continue working just 
   fine. Nobody is talking about banning the use of the word "master" 
   for any existing branches. I am 100% certain that Linux mainline will 
   continue to happen in refs/heads/master, because the fallout of 
   renaming that would be terrible.

4. In Git, local branch names do not need to map to remote branch names.  
   Your local branch "upstream" can track remote branch "development".  
   If the remote branch gets renamed, you simply update your 
   configuration and continue without change.

5. The change proposal has two parts to it:

   1. Allow users of Git to designate another branch as their primary.  
      As Junio pointed out, Git treats one of the branches as special, 
      but currently that is hardcoded to "master". This change will make 
      this configurable so that projects with different naming 
      conventions can designate some other branch as their primary.
      I've seen no objection to this from anyone.

   2. Consider if the default branch created during "git init" should be 
      called "master" or if it should be called something else. Options 
      are to keep it "master" for legacy reasons or to make it something 
      more descriptive like "main". Since this would be merely the 
      default configuration option, packagers and sysops can set it to 
      be whatever they like via /etc/gitconfig, and individual 
      developers can set this in their ~/.gitconfig.

I invite anyone to show just how any of the above is unreasonable.

-K

That would be fine except the entire thread is started on emotionally charged rhetoric

Being that the talk of changing the default name has been said to match up with their efforts how can it be kept off the list? Even the initial start to this pointed to other projects as a reason why this should happen. Seems kind of an odd fence to setup whenever nearly everything about this starts with github and other projects.

My understanding is you can already delete the master branch and force-push that. So back to this topic why does anything need to change?

They may be wrong but being while Git is not a central service is is used in millions of organizations and by millions of organizations through central services such as Github. Through this distributed use some things are assumed whenever creating new repositories and yes the master branch is one of these. Nearly every tutorial on Git or using get will reference the master branch and its is how many people learn. Its already been shown in the patch how these changes might break on existing repos due to assumption of the main/master/primary/<insert word here> branch is no longer what it used to be leading to a need to fix all configs on all repos. Also it has been pointed out how disconnects between configs between two different clones could lead to issues.

Requiring every organization or individual who uses Git to entirely retool due to changes in a base assumption is the exact opposite you want of any stable software. The claim that this only affects new repositories so its immaterial is an odd foot to stand on being that almost all of these scripts assume something about new repositories that will now be different.

While true this is more of an advanced feature that many users don't know about. Saying that its ok because you can fix it with something more complicated sounds like the worst possible reply.

There should be an object to any major change to the underlying code such as this without good reason for doing such. Being that this is not a security issue and as you have pointed out people can already name their branches whatever they like its adding complexity to an already complex system. Being that we are as you say detaching this from "emotionally charged rhetoric" and being "reasonable human beings." what good reason is there to introduce such complexity if users appear to overall not want it and those that do already have an alternative?

I have seen no one in this email chain nor the one asking for what the default name should be even entertain the idea that it should be left at all. Nor have I seen any attempts to accept reasoning for why it shouldn't change. Changing the default while seemingly simple can have long reaching consequences as anyone in development would know. Claiming its merely a default is rather disingenuous for a piece of software as widely used as Git.

I leave with this, if we are to leave out the emotions what good reason is there to push through this change?

-whinis

On Tue, Jun 16, 2020 at 09:55:29AM -0400, John Turner wrote:

And people indeed do that as this thread point out. Git can do better supporting this use case. If people are willing to spend time on that it's their call.

Have you even read what the proposed change is?

It allows changing the name of the branch that is created by git init using a configuration variable. Nothing else.

It is also proposed to change the default for this variable in a future release of git that is expected to have far more disruptive changes, such as different hash used for commit IDs.

Thanks

Michal

One is a rather massive change presumably to prevent collisions and fix a potentially catastrophic failure of a repository, the other could introduce rather massive breaking and disruptive changes..... because? Trying to downplay that its just changing the name is rather disingenuous especially with how much it is changing. Its not a simple rename and breaks a base assumption which is not something that should be done or allowed lightly.

Comparing disruptive changes that are to maintain the actual use and function going forward of the software and one that appears to be fueled solely by an emotional drive without any articulate technical merit so far is an odd choice to make.

And I'm all for it. Having an QoL feature to do something that you could already do is always welcome. We only care about what the default is, for reasons already mentioned. Having an extra flag requires user input, the user knows about that their main branch is something other than the default master.

Most user won't be using this flag, and they will stick to the default. And when they start using a service, that service also assumes that the default name is the same. These services are probably already configurable to change on which branch they operate because git also allows to change it already.

But many people will just stick to the default. When these services change this assumption, everyone else who relied on it has to explicitly set the service back, or rename.

One example is shields.io https://github.com/badges/shields/issues/5215

Changing the default is frowned upon because it solves nothing and just causes problems, as other services has to change their assumptions. (And this doesn't make them bad software as others said previously. If you have to interact with a repository remotely without being able to ask questions first, you have to make assumptions to provide optional parameters, and these optional parameters will only be set if you know that you don't use the expected default, and many people already did, breaking their setup when the service provider changes this assumption) Giving the ability to change it more easily than before, is a welcome change.

What git can't control anyway is what GitHub, GitLab and the others will do, and they already can without changing anything. If GitHub decides to break these services and cause fragmentation, that's a thing not to be discussed here.

And if they do cause fragmentation and git will be the last to keep the convention, it will sadly have no choice but to bend, just to mitigate further damage.

On Tue, Jun 16, 2020 at 09:55:29AM -0400, John Turner wrote:

Github is an equal partner in this conversation and their opinions weigh about as much as anyone else's. However, they are certainly one of the larger users of Git, so if they ask to make it possible to change the default branch name without any negative effects on how Git works, this is a valid request and a valid discussion.

It doesn't work perfectly. The goal is to improve it so it does.

This is true for all technical documentation, though. 10 years ago I could reasonably expect "print foo" to work in Python, but now it will return an error. Most documentation written for the Linux kernel is woefully outdated a few years after its publication.

Documentation has never prevented projects from implementing changes that would require docs to be updated.

As this change would be made by individual repository maintainers, this is out of scope of this discussion. None of the changes being discussed would in any way force existing repositories to rename their branches.

"Entirely retool" is not a fair statement for "set a single config value in a single file".

You can't avoid the following facts:

1. Projects are already renaming their branches to whatever they want
2. There are parts of git where this breaks internal logic
3. We should fix internal logic so it doesn't break

The fact that Git doesn't 100% work with arbitrary branch names is a bug that needs to be fixed. Introducing a config variable that designates the primary branch name is the way to fix it.

Nobody is preventing you from being that person.

Most software development is reactive to emergent situations. In my view, making it possible for someone to have an arbitrary collection of branches in their repository is reason enough to push this change.

-K

On 6/16/2020 11:49 AM, Konstantin Ryabitsev wrote:

This makes me highly confused because just one email earlier said to leave them off this list and now you are saying in one line their opinion weighs as much as everyone else and then say they are a larger user so if they ask it should happen. You have quickly jumped from their opinion shouldn't matter to its equal to their opinion is apparently worth more because they are a large user.

So which is it? Should they be left off the list or is the mere fact they are changing something enough to ignore what this could break?

A single project not conforming is different than changing the default and forcing all documentation to be updated. Not to mention this very well could cause a split in the community itself leading to even more issue. print in python is a poor example as it had obvious technical merit to remove items that did not match other paradigms in the language. Also the Linux Kernel ABI is extremely well documented and even items from 10 years or even 20 years ago conform to it. My argument is not documentation alone should never be updated its that this is a fundamental change invaliding essentially all current available resources. A change this large should require just as large a reason to implement.

So the effect of changes to how the default install works on users is out of scope? What exactly is in scope then because other services were out of scope earlier but now are apparently an important input. I would say how this change affects the majority of users is very much the exact reason this should not happen.

Kinda disagrees with the definition of default doesn't it if your fix is to tell everyone using current tools to change the default back to what it was so it continues to work? Its nearly impossible to estimate how many things were coded by different interns and are now technical debt and would need to be changed either in all future deployments defeating the point of a default or require significant work to rework.

Asking all users to change their methods going forward or rework all their technical debt are both extremely unfair to users.

1. If they are already renaming their branches then they have no issues

2. if there is bugs that needs to be fixed but no where have I seen 
examples where this breaks and need I remind you the title of the list 
is "Rename offensive terminology (master)" which is not saying things 
are broken but that things must change due to offense.

What is an example of Git not working with arbitrary branch names? What fix does changing the primary branch name fix if the issue is with arbitrary branch names?

Then consider me that person.

You yourself have admitted its already possible to have an arbitrary collection of branches, so what does this change?

 >Let's leave emotionally charged rhetoric and discuss this like 
reasonable human beings.

Oh, now we put emotions aside? This whole thing started because white people FELT like black people FELT offended by the word "master" on it's own. But if that's the case, I'll just argue there is no need to avoid the word master at all. After all, feeling aside, right?

On Tue, Jun 16, 2020 at 09:30:54AM -0400, Konstantin Ryabitsev wrote:

If we were all reasonable human beings, then this "useful" feature would wait in order until other really useful things to be done.

Some :-)? This "some" are very few people/projects and no one of them have serious reasons to do it(it pampering).

You are simply lie, because i don't think that you don't understand that this statement is wrong. If so, why this "useful" feature didn't appear earlier? So many people/projects suffer without it all time until today, isn't it?

And what do stop from doing this now? Existent master branch?

No. They wann't. Tell you as cyrillic user, some conventions exist that branches and tags should be in ASCII(no one with a sane mind want to not to do so). And if you want to make a public repo and collaborate with others you will use ASCII in any case. Otherwise nobody understand you.

Hm... Is this a technical reason? So, i've read some fantasies and nothing that looks like technical reasons for such changes.

May be they assume this, because about 15 years master branch was *always* here, didn't think about it :-D? And nobody told that somebody will come and break it somewhen.

We have so little problems and difficulties, that yet another one willn't make our life more hard.

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

It doesn't matter how few repositories need it. If you've been on this list, you would have seen patches being submitted and accepted that fix bugs in corner cases that can't possibly be experienced by the vast majority of Git users.

For the same reason any other useful feature didn't appear earlier. Nobody has brought it up or spent enough time considering it.

1C scripting language is written entirely in Russian. Many official Russian sites use .рф domain names. If someone wants to make all their branch names in Cyrillic, why should we prevent them from doing so?

Very soon we'll break git hashes from being sha1 by default. Just because they've been sha1 for the past 15 years doesn't mean we shouldn't or can't do it.

Then raise this with your upstream repository -- it's not a Git issue.

-K

On Tue, Jun 16, 2020 at 12:03:49PM -0400, Konstantin Ryabitsev wrote:

"master" branch is not the bug. There is nothing to fix here. There is need to fix something in somebody heads, not in the code.

This feature isn't considered enough time. It like a rocket.

1C is a bad example and you know this :-).

Because there are no such people. You try to fix non-existent problem.

Hm. No. Replacing of sha1 have technical reasons and this change have not. If "master" name will stay as a default, this change will make at least some sense.

Somebody, may be you, told here that this "amazing feature" can be easily configured with help of configuration files in any distros. So, let's set "master" name a default and github(i'm shure it have at least one competent admin that can edit a config file of git) change this setting by itself. It's logically correct to set default to a value that *most* users want and give a minority a way to change this setting.

On Tue, Jun 16, 2020 at 08:27:49PM +0300, Oleg wrote:

We can reasonably expect that there will be a government decree coming out tomorrow that will make it illegal to use non-cyrillic terminology in government projects. You know this is entirely possible.

(Heck, every time we promote "pu" to "master" it can be seen as politically charged commentary on current Russian events.)

-K

But politically-charged events in Russia do not affect people outside much. Also most of it is totally ignored inside too.

On Tue, Jun 16, 2020 at 8:43 PM Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

On Tue, Jun 16, 2020 at 01:42:06PM -0400, Konstantin Ryabitsev wrote:

No. This is not possible. This is a fantasy.

"current Russian events" :-D? And what are these current events?