git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* Rename offensive terminology (master)
@ 2020-05-04 17:20 Simon Pieters
  2020-05-04 17:43 ` Robert P. J. Day
                   ` (14 more replies)
  0 siblings, 15 replies; 151+ messages in thread
From: Simon Pieters @ 2020-05-04 17:20 UTC (permalink / raw)
  To: git

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
@ 2020-05-04 17:43 ` Robert P. J. Day
  2020-05-04 23:10   ` N6Ghost
  2020-05-04 17:45 ` Konstantin Ryabitsev
                   ` (13 subsequent siblings)
  14 siblings, 1 reply; 151+ messages in thread
From: Robert P. J. Day @ 2020-05-04 17:43 UTC (permalink / raw)
  To: Simon Pieters; +Cc: git

On Mon, 4 May 2020, Simon Pieters wrote:

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

  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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
  2020-05-04 17:43 ` Robert P. J. Day
@ 2020-05-04 17:45 ` Konstantin Ryabitsev
  2020-05-04 18:31   ` Simon Pieters
  2020-05-04 17:53 ` Robert P. J. Day
                   ` (12 subsequent siblings)
  14 siblings, 1 reply; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-05-04 17:45 UTC (permalink / raw)
  To: Simon Pieters; +Cc: git

On Mon, May 04, 2020 at 07:20:33PM +0200, Simon Pieters wrote:
> "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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
  2020-05-04 17:43 ` Robert P. J. Day
  2020-05-04 17:45 ` Konstantin Ryabitsev
@ 2020-05-04 17:53 ` Robert P. J. Day
  2020-05-04 18:18   ` Randall S. Becker
  2020-05-05 23:16 ` brian m. carlson
                   ` (11 subsequent siblings)
  14 siblings, 1 reply; 151+ messages in thread
From: Robert P. J. Day @ 2020-05-04 17:53 UTC (permalink / raw)
  To: Simon Pieters; +Cc: git

On Mon, 4 May 2020, Simon Pieters wrote:

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

  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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* RE: Rename offensive terminology (master)
  2020-05-04 17:53 ` Robert P. J. Day
@ 2020-05-04 18:18   ` Randall S. Becker
  0 siblings, 0 replies; 151+ messages in thread
From: Randall S. Becker @ 2020-05-04 18:18 UTC (permalink / raw)
  To: 'Robert P. J. Day', 'Simon Pieters'; +Cc: git

On May 4, 2020 1:54 PM, Robert P. J. Day Wrote:
> On Mon, 4 May 2020, Simon Pieters wrote:
> 
> > "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_co
> > ncerns
> >
> > 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
> 
>   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.

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:45 ` Konstantin Ryabitsev
@ 2020-05-04 18:31   ` Simon Pieters
  0 siblings, 0 replies; 151+ messages in thread
From: Simon Pieters @ 2020-05-04 18:31 UTC (permalink / raw)
  To: Simon Pieters; +Cc: git

On Mon, May 4, 2020 at 7:45 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Mon, May 04, 2020 at 07:20:33PM +0200, Simon Pieters wrote:
> > "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
>
> 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.

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
-- 
Simon Pieters
Bocoup https://bocoup.com/

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:43 ` Robert P. J. Day
@ 2020-05-04 23:10   ` N6Ghost
  0 siblings, 0 replies; 151+ messages in thread
From: N6Ghost @ 2020-05-04 23:10 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Simon Pieters, git

On Mon, May 04, 2020 at 01:43:15PM -0400, Robert P. J. Day wrote:
> On Mon, 4 May 2020, Simon Pieters wrote:
> 
> > "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.
> 
>   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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (2 preceding siblings ...)
  2020-05-04 17:53 ` Robert P. J. Day
@ 2020-05-05 23:16 ` brian m. carlson
  2020-06-09 15:16   ` Simon Pieters
                     ` (2 more replies)
  2020-06-13 23:53 ` Sérgio Augusto Vianna
                   ` (10 subsequent siblings)
  14 siblings, 3 replies; 151+ messages in thread
From: brian m. carlson @ 2020-05-05 23:16 UTC (permalink / raw)
  To: Simon Pieters; +Cc: git

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

On 2020-05-04 at 17:20:33, Simon Pieters wrote:
> "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.

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.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-05 23:16 ` brian m. carlson
@ 2020-06-09 15:16   ` Simon Pieters
  2020-06-09 16:02     ` Junio C Hamano
                       ` (3 more replies)
  2020-06-10 21:30   ` Johannes Schindelin
  2020-06-13 23:56   ` Sérgio Augusto Vianna
  2 siblings, 4 replies; 151+ messages in thread
From: Simon Pieters @ 2020-06-09 15:16 UTC (permalink / raw)
  To: brian m. carlson, git; +Cc: don

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:
>
> On 2020-05-04 at 17:20:33, Simon Pieters wrote:
> > "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.
>
> 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.
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204



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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 15:16   ` Simon Pieters
@ 2020-06-09 16:02     ` Junio C Hamano
  2020-06-09 16:28       ` demerphq
                         ` (2 more replies)
  2020-06-09 16:06     ` Konstantin Ryabitsev
                       ` (2 subsequent siblings)
  3 siblings, 3 replies; 151+ messages in thread
From: Junio C Hamano @ 2020-06-09 16:02 UTC (permalink / raw)
  To: Simon Pieters; +Cc: brian m. carlson, git, don

Simon Pieters <simon@bocoup.com> writes:

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

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 15:16   ` Simon Pieters
  2020-06-09 16:02     ` Junio C Hamano
@ 2020-06-09 16:06     ` Konstantin Ryabitsev
  2020-06-09 19:01       ` Don Goodman-Wilson
  2020-06-09 22:36     ` brian m. carlson
  2020-06-16  8:50     ` Michal Suchánek
  3 siblings, 1 reply; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-09 16:06 UTC (permalink / raw)
  To: Simon Pieters; +Cc: brian m. carlson, git, don

On Tue, Jun 09, 2020 at 05:16:57PM +0200, Simon Pieters wrote:
> 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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 16:02     ` Junio C Hamano
@ 2020-06-09 16:28       ` demerphq
  2020-06-09 18:10       ` Johannes Sixt
  2020-06-09 20:52       ` Simon Pieters
  2 siblings, 0 replies; 151+ messages in thread
From: demerphq @ 2020-06-09 16:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Simon Pieters, brian m. carlson, Git, don

On Tue, 9 Jun 2020 at 18:05, Junio C Hamano <gitster@pobox.com> wrote:
>
> Simon Pieters <simon@bocoup.com> writes:
>
> > 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.
>
> 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).

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






-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 16:02     ` Junio C Hamano
  2020-06-09 16:28       ` demerphq
@ 2020-06-09 18:10       ` Johannes Sixt
  2020-06-09 19:02         ` Junio C Hamano
  2020-06-09 20:52       ` Simon Pieters
  2 siblings, 1 reply; 151+ messages in thread
From: Johannes Sixt @ 2020-06-09 18:10 UTC (permalink / raw)
  To: Simon Pieters; +Cc: Junio C Hamano, brian m. carlson, git, don

Am 09.06.20 um 18:02 schrieb Junio C Hamano:
> 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,...

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

-- Hannes

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 16:06     ` Konstantin Ryabitsev
@ 2020-06-09 19:01       ` Don Goodman-Wilson
  2020-06-14  0:05         ` Sérgio Augusto Vianna
  0 siblings, 1 reply; 151+ messages in thread
From: Don Goodman-Wilson @ 2020-06-09 19:01 UTC (permalink / raw)
  To: Simon Pieters, brian m. carlson, git, don

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:
>
> On Tue, Jun 09, 2020 at 05:16:57PM +0200, Simon Pieters wrote:
> > 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.
>
> 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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 18:10       ` Johannes Sixt
@ 2020-06-09 19:02         ` Junio C Hamano
  0 siblings, 0 replies; 151+ messages in thread
From: Junio C Hamano @ 2020-06-09 19:02 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: Simon Pieters, brian m. carlson, git, don

Johannes Sixt <j6t@kdbg.org> writes:

> Am 09.06.20 um 18:02 schrieb Junio C Hamano:
>> 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,...
>
> Don't forget the special treatment of "master" in fmt-merge-msg.c that
> skips the " into 'foo'" part of  "Merge branch 'bar'".

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 16:02     ` Junio C Hamano
  2020-06-09 16:28       ` demerphq
  2020-06-09 18:10       ` Johannes Sixt
@ 2020-06-09 20:52       ` Simon Pieters
  2020-06-09 21:03         ` Junio C Hamano
                           ` (2 more replies)
  2 siblings, 3 replies; 151+ messages in thread
From: Simon Pieters @ 2020-06-09 20:52 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: brian m. carlson, git, don

Hi Junio,

On Tue, Jun 9, 2020 at 6:02 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Simon Pieters <simon@bocoup.com> writes:
>
> > 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.
>
> 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.

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,

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


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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 20:52       ` Simon Pieters
@ 2020-06-09 21:03         ` Junio C Hamano
  2020-06-09 21:29           ` Simon Pieters
  2020-06-10  9:51         ` Robert P. J. Day
  2020-06-14  0:00         ` Sérgio Augusto Vianna
  2 siblings, 1 reply; 151+ messages in thread
From: Junio C Hamano @ 2020-06-09 21:03 UTC (permalink / raw)
  To: Simon Pieters; +Cc: brian m. carlson, git, don

Simon Pieters <simon@bocoup.com> writes:

> Hi Junio,
>
> On Tue, Jun 9, 2020 at 6:02 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Simon Pieters <simon@bocoup.com> writes:
>>
>> > 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.
>>
>> 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.
>
> I find this response not satisfactory:

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 ;-)

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 21:03         ` Junio C Hamano
@ 2020-06-09 21:29           ` Simon Pieters
  0 siblings, 0 replies; 151+ messages in thread
From: Simon Pieters @ 2020-06-09 21:29 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: brian m. carlson, git, don

On Tue, Jun 9, 2020 at 11:03 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> > I find this response not satisfactory:
>
> And I find that response quite offensive.

I'm sorry I offended you.

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

OK. I agree!

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

OK.

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

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 15:16   ` Simon Pieters
  2020-06-09 16:02     ` Junio C Hamano
  2020-06-09 16:06     ` Konstantin Ryabitsev
@ 2020-06-09 22:36     ` brian m. carlson
  2020-06-16  8:50     ` Michal Suchánek
  3 siblings, 0 replies; 151+ messages in thread
From: brian m. carlson @ 2020-06-09 22:36 UTC (permalink / raw)
  To: Simon Pieters; +Cc: git, don

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

On 2020-06-09 at 15:16:57, Simon Pieters wrote:
> 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

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.

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

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.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 20:52       ` Simon Pieters
  2020-06-09 21:03         ` Junio C Hamano
@ 2020-06-10  9:51         ` Robert P. J. Day
  2020-06-10 11:16           ` Kevin Swinton
  2020-06-10 12:18           ` Don Goodman-Wilson
  2020-06-14  0:00         ` Sérgio Augusto Vianna
  2 siblings, 2 replies; 151+ messages in thread
From: Robert P. J. Day @ 2020-06-10  9:51 UTC (permalink / raw)
  To: Simon Pieters; +Cc: Junio C Hamano, brian m. carlson, git, don

On Tue, 9 Jun 2020, Simon Pieters wrote:

> Hi Junio,
>
> On Tue, Jun 9, 2020 at 6:02 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Simon Pieters <simon@bocoup.com> writes:
> >
> > > 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.
> >
> > 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.
>
> I find this response not satisfactory:

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10  9:51         ` Robert P. J. Day
@ 2020-06-10 11:16           ` Kevin Swinton
  2020-06-10 12:18           ` Don Goodman-Wilson
  1 sibling, 0 replies; 151+ messages in thread
From: Kevin Swinton @ 2020-06-10 11:16 UTC (permalink / raw)
  To: Robert P. J. Day
  Cc: Simon Pieters, Junio C Hamano, brian m. carlson, git, don

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:
>
> On Tue, 9 Jun 2020, Simon Pieters wrote:
>
> > Hi Junio,
> >
> > On Tue, Jun 9, 2020 at 6:02 PM Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > > Simon Pieters <simon@bocoup.com> writes:
> > >
> > > > 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.
> > >
> > > 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.
> >
> > I find this response not satisfactory:
>
>   ... 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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10  9:51         ` Robert P. J. Day
  2020-06-10 11:16           ` Kevin Swinton
@ 2020-06-10 12:18           ` Don Goodman-Wilson
  2020-06-10 16:30             ` Konstantin Ryabitsev
  2020-06-14  0:03             ` Sérgio Augusto Vianna
  1 sibling, 2 replies; 151+ messages in thread
From: Don Goodman-Wilson @ 2020-06-10 12:18 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Simon Pieters, Junio C Hamano, brian m. carlson, git

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 Tue, 9 Jun 2020, Simon Pieters wrote:
>
> > Hi Junio,
> >
> > On Tue, Jun 9, 2020 at 6:02 PM Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > > Simon Pieters <simon@bocoup.com> writes:
> > >
> > > > 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.
> > >
> > > 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.
> >
> > I find this response not satisfactory:
>
>   ... 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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10 12:18           ` Don Goodman-Wilson
@ 2020-06-10 16:30             ` Konstantin Ryabitsev
  2020-06-14  0:03             ` Sérgio Augusto Vianna
  1 sibling, 0 replies; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-10 16:30 UTC (permalink / raw)
  To: Don Goodman-Wilson
  Cc: Robert P. J. Day, Simon Pieters, Junio C Hamano,
	brian m. carlson, Git Mailing List

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

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

-K

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-05 23:16 ` brian m. carlson
  2020-06-09 15:16   ` Simon Pieters
@ 2020-06-10 21:30   ` Johannes Schindelin
  2020-06-10 22:35     ` Edward Thomson
                       ` (5 more replies)
  2020-06-13 23:56   ` Sérgio Augusto Vianna
  2 siblings, 6 replies; 151+ messages in thread
From: Johannes Schindelin @ 2020-06-10 21:30 UTC (permalink / raw)
  To: brian m. carlson; +Cc: Simon Pieters, Don Goodman-Wilson, git

Hi all,

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

> On 2020-05-04 at 17:20:33, Simon Pieters wrote:
> > "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.
>
> 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.

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

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

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.

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

Indeed.

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

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

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

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

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?

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

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

> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204
>

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10 21:30   ` Johannes Schindelin
@ 2020-06-10 22:35     ` Edward Thomson
  2020-06-10 22:51     ` brian m. carlson
                       ` (4 subsequent siblings)
  5 siblings, 0 replies; 151+ messages in thread
From: Edward Thomson @ 2020-06-10 22:35 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: brian m. carlson, Simon Pieters, Don Goodman-Wilson, git

On Wed, Jun 10, 2020 at 11:30:31PM +0200, Johannes Schindelin wrote:
> 
> 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?

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

Thanks-
-ed

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10 21:30   ` Johannes Schindelin
  2020-06-10 22:35     ` Edward Thomson
@ 2020-06-10 22:51     ` brian m. carlson
  2020-06-11 11:52     ` Michal Suchánek
                       ` (3 subsequent siblings)
  5 siblings, 0 replies; 151+ messages in thread
From: brian m. carlson @ 2020-06-10 22:51 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Simon Pieters, Don Goodman-Wilson, git

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

On 2020-06-10 at 21:30:31, Johannes Schindelin wrote:
> 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 appreciate you working on these patches and also your consideration
for the SHA-256 work.

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

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.

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

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

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

I'm interested in participating as well.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10 21:30   ` Johannes Schindelin
  2020-06-10 22:35     ` Edward Thomson
  2020-06-10 22:51     ` brian m. carlson
@ 2020-06-11 11:52     ` Michal Suchánek
  2020-06-11 11:59       ` Don Goodman-Wilson
  2020-06-15  0:34     ` James Ramsay
                       ` (2 subsequent siblings)
  5 siblings, 1 reply; 151+ messages in thread
From: Michal Suchánek @ 2020-06-11 11:52 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: brian m. carlson, Simon Pieters, Don Goodman-Wilson, git

On Wed, Jun 10, 2020 at 11:30:31PM +0200, Johannes Schindelin wrote:
> Hi all,
> 
> On Tue, 5 May 2020, brian m. carlson wrote:
> 
> > On 2020-05-04 at 17:20:33, Simon Pieters wrote:
...
> > 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.
> 
> 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 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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-11 11:52     ` Michal Suchánek
@ 2020-06-11 11:59       ` Don Goodman-Wilson
  2020-06-11 12:52         ` Derrick Stolee
  0 siblings, 1 reply; 151+ messages in thread
From: Don Goodman-Wilson @ 2020-06-11 11:59 UTC (permalink / raw)
  To: Michal Suchánek
  Cc: Johannes Schindelin, brian m. carlson, Simon Pieters, git

On Thu, Jun 11, 2020 at 1:52 PM Michal Suchánek <msuchanek@suse.de> 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.

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

Don Goodman-Wilson

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-11 11:59       ` Don Goodman-Wilson
@ 2020-06-11 12:52         ` Derrick Stolee
  2020-06-11 15:14           ` Junio C Hamano
  2020-06-12 13:21           ` Philip Oakley
  0 siblings, 2 replies; 151+ messages in thread
From: Derrick Stolee @ 2020-06-11 12:52 UTC (permalink / raw)
  To: Don Goodman-Wilson, Michal Suchánek
  Cc: Johannes Schindelin, brian m. carlson, Simon Pieters, git

On 6/11/2020 7:59 AM, Don Goodman-Wilson wrote:
> On Thu, Jun 11, 2020 at 1:52 PM Michal Suchánek <msuchanek@suse.de> 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.
> 
> I _really_ like this idea (and your reasoning). Seconded.

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

Thanks,
-Stolee

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-11 12:52         ` Derrick Stolee
@ 2020-06-11 15:14           ` Junio C Hamano
  2020-06-14  2:59             ` Johannes Schindelin
  2020-06-12 13:21           ` Philip Oakley
  1 sibling, 1 reply; 151+ messages in thread
From: Junio C Hamano @ 2020-06-11 15:14 UTC (permalink / raw)
  To: Derrick Stolee
  Cc: Don Goodman-Wilson, Michal Suchánek, Johannes Schindelin,
	brian m. carlson, Simon Pieters, git

Derrick Stolee <stolee@gmail.com> writes:

> On 6/11/2020 7:59 AM, Don Goodman-Wilson wrote:
>> On Thu, Jun 11, 2020 at 1:52 PM Michal Suchánek <msuchanek@suse.de> 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.
>> 
>> I _really_ like this idea (and your reasoning). Seconded.
>
> Yes, adding a -b|--branch option would be an excellent addition to
> the config option.

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.

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-11 12:52         ` Derrick Stolee
  2020-06-11 15:14           ` Junio C Hamano
@ 2020-06-12 13:21           ` Philip Oakley
  2020-06-14  0:41             ` Elijah Newren
  1 sibling, 1 reply; 151+ messages in thread
From: Philip Oakley @ 2020-06-12 13:21 UTC (permalink / raw)
  To: Derrick Stolee, Don Goodman-Wilson, Michal Suchánek
  Cc: Johannes Schindelin, brian m. carlson, Simon Pieters, git

On 11/06/2020 13:52, Derrick Stolee wrote:
> On 6/11/2020 7:59 AM, Don Goodman-Wilson wrote:
>> On Thu, Jun 11, 2020 at 1:52 PM Michal Suchánek <msuchanek@suse.de> 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.
>> I _really_ like this idea (and your reasoning). Seconded.
> Yes, adding a -b|--branch option would be an excellent addition to
> the config option.
>
>
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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (3 preceding siblings ...)
  2020-05-05 23:16 ` brian m. carlson
@ 2020-06-13 23:53 ` Sérgio Augusto Vianna
  2020-06-14 14:59 ` Thomas Adam
                   ` (9 subsequent siblings)
  14 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-13 23:53 UTC (permalink / raw)
  To: simon; +Cc: git

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-05 23:16 ` brian m. carlson
  2020-06-09 15:16   ` Simon Pieters
  2020-06-10 21:30   ` Johannes Schindelin
@ 2020-06-13 23:56   ` Sérgio Augusto Vianna
  2 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-13 23:56 UTC (permalink / raw)
  To: sandals; +Cc: git, simon

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.

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 20:52       ` Simon Pieters
  2020-06-09 21:03         ` Junio C Hamano
  2020-06-10  9:51         ` Robert P. J. Day
@ 2020-06-14  0:00         ` Sérgio Augusto Vianna
  2020-06-14  0:45           ` Junio C Hamano
  2 siblings, 1 reply; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14  0:00 UTC (permalink / raw)
  To: simon; +Cc: don, git, gitster, sandals

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

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10 12:18           ` Don Goodman-Wilson
  2020-06-10 16:30             ` Konstantin Ryabitsev
@ 2020-06-14  0:03             ` Sérgio Augusto Vianna
  1 sibling, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14  0:03 UTC (permalink / raw)
  To: don; +Cc: git, gitster, rpjday, sandals, simon

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 19:01       ` Don Goodman-Wilson
@ 2020-06-14  0:05         ` Sérgio Augusto Vianna
  2020-06-14 19:08           ` brian m. carlson
  0 siblings, 1 reply; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14  0:05 UTC (permalink / raw)
  To: don; +Cc: git, sandals, simon

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-12 13:21           ` Philip Oakley
@ 2020-06-14  0:41             ` Elijah Newren
  2020-06-14 10:54               ` Philip Oakley
  0 siblings, 1 reply; 151+ messages in thread
From: Elijah Newren @ 2020-06-14  0:41 UTC (permalink / raw)
  To: Philip Oakley
  Cc: Derrick Stolee, Don Goodman-Wilson, Michal Suchánek,
	Johannes Schindelin, brian m. carlson, Simon Pieters,
	Git Mailing List

On Fri, Jun 12, 2020 at 6:23 AM Philip Oakley <philipoakley@iee.email> wrote:
>
> On 11/06/2020 13:52, Derrick Stolee wrote:
> > On 6/11/2020 7:59 AM, Don Goodman-Wilson wrote:
> >> On Thu, Jun 11, 2020 at 1:52 PM Michal Suchánek <msuchanek@suse.de> 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.
> >> I _really_ like this idea (and your reasoning). Seconded.
> > Yes, adding a -b|--branch option would be an excellent addition to
> > the config option.
> >
> >
> 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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  0:00         ` Sérgio Augusto Vianna
@ 2020-06-14  0:45           ` Junio C Hamano
  2020-06-14  0:50             ` Sérgio Augusto Vianna
  0 siblings, 1 reply; 151+ messages in thread
From: Junio C Hamano @ 2020-06-14  0:45 UTC (permalink / raw)
  To: Sérgio Augusto Vianna; +Cc: simon, don, git, sandals

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

>>as far as I can tell, no evidence that "main" offends anyone.
>
> I'm offended by "main". What now?

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.

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  0:45           ` Junio C Hamano
@ 2020-06-14  0:50             ` Sérgio Augusto Vianna
  2020-06-14  6:32               ` Don Goodman-Wilson
  2020-06-16 10:04               ` Alex Smith
  0 siblings, 2 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14  0:50 UTC (permalink / raw)
  To: gitster; +Cc: don, git, sandals, sergio.a.vianna, simon

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-11 15:14           ` Junio C Hamano
@ 2020-06-14  2:59             ` Johannes Schindelin
  2020-06-15 10:07               ` Michal Suchánek
  0 siblings, 1 reply; 151+ messages in thread
From: Johannes Schindelin @ 2020-06-14  2:59 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Derrick Stolee, Don Goodman-Wilson, Michal Suchánek,
	brian m. carlson, Simon Pieters, git

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

Hi,

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

> Derrick Stolee <stolee@gmail.com> writes:
>
> > On 6/11/2020 7:59 AM, Don Goodman-Wilson wrote:
> >> On Thu, Jun 11, 2020 at 1:52 PM Michal Suchánek <msuchanek@suse.de> 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.
> >>
> >> I _really_ like this idea (and your reasoning). Seconded.
> >
> > Yes, adding a -b|--branch option would be an excellent addition to
> > the config option.
>
> 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.

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

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  0:50             ` Sérgio Augusto Vianna
@ 2020-06-14  6:32               ` Don Goodman-Wilson
  2020-06-14  6:34                 ` Don Goodman-Wilson
  2020-06-16  7:31                 ` demerphq
  2020-06-16 10:04               ` Alex Smith
  1 sibling, 2 replies; 151+ messages in thread
From: Don Goodman-Wilson @ 2020-06-14  6:32 UTC (permalink / raw)
  To: Sérgio Augusto Vianna
  Cc: Junio C Hamano, git, brian m. carlson, Simon Pieters

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  6:32               ` Don Goodman-Wilson
@ 2020-06-14  6:34                 ` Don Goodman-Wilson
  2020-06-14  8:47                   ` Sergey Lapin
  2020-06-14 12:07                   ` Sérgio Augusto Vianna
  2020-06-16  7:31                 ` demerphq
  1 sibling, 2 replies; 151+ messages in thread
From: Don Goodman-Wilson @ 2020-06-14  6:34 UTC (permalink / raw)
  To: Sérgio Augusto Vianna
  Cc: Junio C Hamano, git, brian m. carlson, Simon Pieters

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 14:59 ` Thomas Adam
@ 2020-06-14  8:04   ` Johannes Schindelin
  2020-06-14 15:13   ` Michael Felt (aixtools)
  1 sibling, 0 replies; 151+ messages in thread
From: Johannes Schindelin @ 2020-06-14  8:04 UTC (permalink / raw)
  To: Thomas Adam; +Cc: Simon Pieters, Git Users

Hi Thomas,

On Sun, 14 Jun 2020, Thomas Adam wrote:

> On Mon, 4 May 2020 at 18:22, Simon Pieters <simon@bocoup.com> wrote:
> > 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.
>
> 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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 15:13   ` Michael Felt (aixtools)
@ 2020-06-14  8:27     ` Johannes Schindelin
  2020-06-14 15:51     ` George Of The Jungle
  1 sibling, 0 replies; 151+ messages in thread
From: Johannes Schindelin @ 2020-06-14  8:27 UTC (permalink / raw)
  To: Michael Felt (aixtools); +Cc: Thomas Adam, Simon Pieters, Git Users

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

Hi Michael,

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

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  6:34                 ` Don Goodman-Wilson
@ 2020-06-14  8:47                   ` Sergey Lapin
  2020-06-14  8:48                     ` Sergey Lapin
  2020-06-14 12:07                   ` Sérgio Augusto Vianna
  1 sibling, 1 reply; 151+ messages in thread
From: Sergey Lapin @ 2020-06-14  8:47 UTC (permalink / raw)
  To: Don Goodman-Wilson
  Cc: Sérgio Augusto Vianna, Junio C Hamano, git,
	brian m. carlson, Simon Pieters

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  8:47                   ` Sergey Lapin
@ 2020-06-14  8:48                     ` Sergey Lapin
  0 siblings, 0 replies; 151+ messages in thread
From: Sergey Lapin @ 2020-06-14  8:48 UTC (permalink / raw)
  To: Don Goodman-Wilson
  Cc: Sérgio Augusto Vianna, Junio C Hamano, git,
	brian m. carlson, Simon Pieters

And I'm also offended by "main"

On Sun, Jun 14, 2020 at 11:47 AM Sergey Lapin <slapinid@gmail.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:
> >
> > (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:
> > >
> > > 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:
> > > >
> > > > 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.
> > > >

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 19:08           ` brian m. carlson
@ 2020-06-14  8:49             ` Johannes Schindelin
  2020-06-14 19:17             ` Sérgio Augusto Vianna
  2020-06-15  2:16             ` Taylor Blau
  2 siblings, 0 replies; 151+ messages in thread
From: Johannes Schindelin @ 2020-06-14  8:49 UTC (permalink / raw)
  To: brian m. carlson; +Cc: Sérgio Augusto Vianna, don, git, simon

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

Hi brian,

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

> On 2020-06-14 at 00:05:33, Sérgio Augusto Vianna 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.
>
> 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.

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

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.

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  0:41             ` Elijah Newren
@ 2020-06-14 10:54               ` Philip Oakley
  2020-06-14 12:20                 ` Sérgio Augusto Vianna
  0 siblings, 1 reply; 151+ messages in thread
From: Philip Oakley @ 2020-06-14 10:54 UTC (permalink / raw)
  To: Elijah Newren
  Cc: Derrick Stolee, Don Goodman-Wilson, Michal Suchánek,
	Johannes Schindelin, brian m. carlson, Simon Pieters,
	Git Mailing List

On 14/06/2020 01:41, Elijah Newren wrote:
> On Fri, Jun 12, 2020 at 6:23 AM Philip Oakley <philipoakley@iee.email> wrote:
>> On 11/06/2020 13:52, Derrick Stolee wrote:
>>> On 6/11/2020 7:59 AM, Don Goodman-Wilson wrote:
>>>> On Thu, Jun 11, 2020 at 1:52 PM Michal Suchánek <msuchanek@suse.de> 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.
>>>> I _really_ like this idea (and your reasoning). Seconded.
>>> Yes, adding a -b|--branch option would be an excellent addition to
>>> the config option.
>>>
>>>
>> 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.
> Good news: git clone already has a `--no-checkout` option (with `-n`
> being the short option form for it).
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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  6:34                 ` Don Goodman-Wilson
  2020-06-14  8:47                   ` Sergey Lapin
@ 2020-06-14 12:07                   ` Sérgio Augusto Vianna
  1 sibling, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14 12:07 UTC (permalink / raw)
  To: don; +Cc: git, gitster, sandals, sergio.a.vianna, simon

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 10:54               ` Philip Oakley
@ 2020-06-14 12:20                 ` Sérgio Augusto Vianna
  2020-06-14 13:58                   ` Don Goodman-Wilson
                                     ` (2 more replies)
  0 siblings, 3 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14 12:20 UTC (permalink / raw)
  To: philipoakley
  Cc: Johannes.Schindelin, don, git, msuchanek, newren, sandals, simon, stolee

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 12:20                 ` Sérgio Augusto Vianna
@ 2020-06-14 13:58                   ` Don Goodman-Wilson
  2020-06-14 14:05                     ` Sérgio Augusto Vianna
                                       ` (2 more replies)
  2020-06-14 18:19                   ` Konstantin Ryabitsev
  2020-06-15 18:07                   ` Jonathan Nieder
  2 siblings, 3 replies; 151+ messages in thread
From: Don Goodman-Wilson @ 2020-06-14 13:58 UTC (permalink / raw)
  To: Sérgio Augusto Vianna
  Cc: philipoakley, Johannes Schindelin, git, Michal Suchánek,
	newren, brian m. carlson, Simon Pieters, stolee

> MASTER IS NOT INHERENTLY RELATED TO MASTER-SLAVE RELATIONS.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 13:58                   ` Don Goodman-Wilson
@ 2020-06-14 14:05                     ` Sérgio Augusto Vianna
  2020-06-15  3:52                     ` Andrew Ardill
  2020-06-17  8:27                     ` Michal Suchánek
  2 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14 14:05 UTC (permalink / raw)
  To: don
  Cc: Johannes.Schindelin, git, msuchanek, newren, philipoakley,
	sandals, sergio.a.vianna, simon, stolee

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (4 preceding siblings ...)
  2020-06-13 23:53 ` Sérgio Augusto Vianna
@ 2020-06-14 14:59 ` Thomas Adam
  2020-06-14  8:04   ` Johannes Schindelin
  2020-06-14 15:13   ` Michael Felt (aixtools)
  2020-06-14 15:20 ` Sérgio Augusto Vianna
                   ` (8 subsequent siblings)
  14 siblings, 2 replies; 151+ messages in thread
From: Thomas Adam @ 2020-06-14 14:59 UTC (permalink / raw)
  To: Simon Pieters; +Cc: Git Users

On Mon, 4 May 2020 at 18:22, Simon Pieters <simon@bocoup.com> wrote:
> 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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 14:59 ` Thomas Adam
  2020-06-14  8:04   ` Johannes Schindelin
@ 2020-06-14 15:13   ` Michael Felt (aixtools)
  2020-06-14  8:27     ` Johannes Schindelin
  2020-06-14 15:51     ` George Of The Jungle
  1 sibling, 2 replies; 151+ messages in thread
From: Michael Felt (aixtools) @ 2020-06-14 15:13 UTC (permalink / raw)
  To: Thomas Adam; +Cc: Simon Pieters, Git Users

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

Sent from my iPhone

> On 14 Jun 2020, at 16:59, Thomas Adam <thomas@xteddy.org> wrote:
> 
> On Mon, 4 May 2020 at 18:22, Simon Pieters <simon@bocoup.com> wrote:
>> 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.
> 
> 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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (5 preceding siblings ...)
  2020-06-14 14:59 ` Thomas Adam
@ 2020-06-14 15:20 ` Sérgio Augusto Vianna
  2020-06-15  0:02 ` Sérgio Augusto Vianna
                   ` (7 subsequent siblings)
  14 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14 15:20 UTC (permalink / raw)
  To: simon; +Cc: git

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 15:13   ` Michael Felt (aixtools)
  2020-06-14  8:27     ` Johannes Schindelin
@ 2020-06-14 15:51     ` George Of The Jungle
  1 sibling, 0 replies; 151+ messages in thread
From: George Of The Jungle @ 2020-06-14 15:51 UTC (permalink / raw)
  To: Michael Felt (aixtools); +Cc: Thomas Adam, Simon Pieters, Git Users

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.

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 12:20                 ` Sérgio Augusto Vianna
  2020-06-14 13:58                   ` Don Goodman-Wilson
@ 2020-06-14 18:19                   ` Konstantin Ryabitsev
  2020-06-14 18:23                     ` Sérgio Augusto Vianna
  2020-06-14 21:06                     ` Junio C Hamano
  2020-06-15 18:07                   ` Jonathan Nieder
  2 siblings, 2 replies; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-14 18:19 UTC (permalink / raw)
  To: Sérgio Augusto Vianna
  Cc: philipoakley, Johannes.Schindelin, don, git, msuchanek, newren,
	sandals, simon, stolee

On Sun, Jun 14, 2020 at 09:20:20AM -0300, Sérgio Augusto Vianna wrote:
> 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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 18:19                   ` Konstantin Ryabitsev
@ 2020-06-14 18:23                     ` Sérgio Augusto Vianna
  2020-06-14 19:04                       ` Konstantin Ryabitsev
                                         ` (2 more replies)
  2020-06-14 21:06                     ` Junio C Hamano
  1 sibling, 3 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14 18:23 UTC (permalink / raw)
  To: konstantin
  Cc: Johannes.Schindelin, don, git, msuchanek, newren, philipoakley,
	sandals, sergio.a.vianna, simon, stolee

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 18:23                     ` Sérgio Augusto Vianna
@ 2020-06-14 19:04                       ` Konstantin Ryabitsev
  2020-06-14 19:08                         ` Sérgio Augusto Vianna
  2020-06-14 20:41                       ` Philip Oakley
  2020-06-16  7:36                       ` demerphq
  2 siblings, 1 reply; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-14 19:04 UTC (permalink / raw)
  To: Sérgio Augusto Vianna
  Cc: Johannes.Schindelin, don, git, msuchanek, newren, philipoakley,
	sandals, simon, stolee

On Sun, Jun 14, 2020 at 03:23:29PM -0300, Sérgio Augusto Vianna wrote:
> Ok, can you show me a single instance where "master" was confusing or not
> descriptive enough? 

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.

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

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.

> I think
> half dozen people can spare a few seconds instead of wasting literally
> everybody else's time fixing their respective software.

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.

> Also, literally no
> one cared until americans went hysterical with the death of that guy in
> Minneapolis.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  0:05         ` Sérgio Augusto Vianna
@ 2020-06-14 19:08           ` brian m. carlson
  2020-06-14  8:49             ` Johannes Schindelin
                               ` (2 more replies)
  0 siblings, 3 replies; 151+ messages in thread
From: brian m. carlson @ 2020-06-14 19:08 UTC (permalink / raw)
  To: Sérgio Augusto Vianna; +Cc: don, git, simon

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

On 2020-06-14 at 00:05:33, Sérgio Augusto Vianna 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.

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.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 19:04                       ` Konstantin Ryabitsev
@ 2020-06-14 19:08                         ` Sérgio Augusto Vianna
  2020-06-14 19:16                           ` Konstantin Ryabitsev
  0 siblings, 1 reply; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14 19:08 UTC (permalink / raw)
  To: konstantin
  Cc: Johannes.Schindelin, don, git, msuchanek, newren, philipoakley,
	sandals, sergio.a.vianna, simon, stolee

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 19:08                         ` Sérgio Augusto Vianna
@ 2020-06-14 19:16                           ` Konstantin Ryabitsev
  0 siblings, 0 replies; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-14 19:16 UTC (permalink / raw)
  To: Sérgio Augusto Vianna
  Cc: Johannes.Schindelin, don, git, msuchanek, newren, philipoakley,
	sandals, simon, stolee

On Sun, Jun 14, 2020 at 04:08:53PM -0300, Sérgio Augusto Vianna wrote:
> >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.

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.

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

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

-K

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 19:08           ` brian m. carlson
  2020-06-14  8:49             ` Johannes Schindelin
@ 2020-06-14 19:17             ` Sérgio Augusto Vianna
  2020-06-15  2:16             ` Taylor Blau
  2 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-14 19:17 UTC (permalink / raw)
  To: sandals; +Cc: don, git, sergio.a.vianna, simon

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 18:23                     ` Sérgio Augusto Vianna
  2020-06-14 19:04                       ` Konstantin Ryabitsev
@ 2020-06-14 20:41                       ` Philip Oakley
  2020-06-16  7:36                       ` demerphq
  2 siblings, 0 replies; 151+ messages in thread
From: Philip Oakley @ 2020-06-14 20:41 UTC (permalink / raw)
  To: Sérgio Augusto Vianna, konstantin
  Cc: Johannes.Schindelin, don, git, msuchanek, newren, sandals, simon, stolee

On 14/06/2020 19:23, Sérgio Augusto Vianna wrote:
> Ok, can you show me a single instance where "master" was confusing or
> not descriptive enough?
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>

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 18:19                   ` Konstantin Ryabitsev
  2020-06-14 18:23                     ` Sérgio Augusto Vianna
@ 2020-06-14 21:06                     ` Junio C Hamano
  2020-06-14 21:15                       ` Eric Wong
  1 sibling, 1 reply; 151+ messages in thread
From: Junio C Hamano @ 2020-06-14 21:06 UTC (permalink / raw)
  To: Konstantin Ryabitsev
  Cc: Sérgio Augusto Vianna, philipoakley, Johannes.Schindelin,
	don, git, msuchanek, newren, sandals, simon, stolee

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 21:06                     ` Junio C Hamano
@ 2020-06-14 21:15                       ` Eric Wong
  2020-06-14 21:39                         ` Junio C Hamano
  0 siblings, 1 reply; 151+ messages in thread
From: Eric Wong @ 2020-06-14 21:15 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Konstantin Ryabitsev, Sérgio Augusto Vianna, philipoakley,
	Johannes.Schindelin, don, git, msuchanek, newren, sandals, simon,
	stolee

Junio C Hamano <gitster@pobox.com> wrote:
> 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).

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 21:15                       ` Eric Wong
@ 2020-06-14 21:39                         ` Junio C Hamano
  0 siblings, 0 replies; 151+ messages in thread
From: Junio C Hamano @ 2020-06-14 21:39 UTC (permalink / raw)
  To: Eric Wong
  Cc: Konstantin Ryabitsev, Sérgio Augusto Vianna, philipoakley,
	Johannes.Schindelin, don, git, msuchanek, newren, sandals, simon,
	stolee

Eric Wong <normalperson@yhbt.net> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> 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).
>
> 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 :>

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.

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (6 preceding siblings ...)
  2020-06-14 15:20 ` Sérgio Augusto Vianna
@ 2020-06-15  0:02 ` Sérgio Augusto Vianna
  2020-06-15 14:39 ` Sérgio Augusto Vianna
                   ` (6 subsequent siblings)
  14 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-15  0:02 UTC (permalink / raw)
  To: simon; +Cc: git

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10 21:30   ` Johannes Schindelin
                       ` (2 preceding siblings ...)
  2020-06-11 11:52     ` Michal Suchánek
@ 2020-06-15  0:34     ` James Ramsay
  2020-06-15 21:38     ` Elijah Newren
  2020-06-16 21:07     ` ZeeVriend
  5 siblings, 0 replies; 151+ messages in thread
From: James Ramsay @ 2020-06-15  0:34 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: brian m. carlson, Simon Pieters, Don Goodman-Wilson, git

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

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

> 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

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

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 19:08           ` brian m. carlson
  2020-06-14  8:49             ` Johannes Schindelin
  2020-06-14 19:17             ` Sérgio Augusto Vianna
@ 2020-06-15  2:16             ` Taylor Blau
  2020-06-15  2:54               ` Sérgio Augusto Vianna
  2 siblings, 1 reply; 151+ messages in thread
From: Taylor Blau @ 2020-06-15  2:16 UTC (permalink / raw)
  To: brian m. carlson, Sérgio Augusto Vianna, don, git, simon

Hi brian,

On Sun, Jun 14, 2020 at 07:08:42PM +0000, brian m. carlson wrote:
> On 2020-06-14 at 00:05:33, Sérgio Augusto Vianna 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.
>
> 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.

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

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

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.

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

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.

> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-15  2:16             ` Taylor Blau
@ 2020-06-15  2:54               ` Sérgio Augusto Vianna
  0 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-15  2:54 UTC (permalink / raw)
  To: me; +Cc: don, git, sandals, sergio.a.vianna, simon

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 13:58                   ` Don Goodman-Wilson
  2020-06-14 14:05                     ` Sérgio Augusto Vianna
@ 2020-06-15  3:52                     ` Andrew Ardill
  2020-06-15  4:45                       ` J. Paul Reed
  2020-06-17  8:27                     ` Michal Suchánek
  2 siblings, 1 reply; 151+ messages in thread
From: Andrew Ardill @ 2020-06-15  3:52 UTC (permalink / raw)
  To: Don Goodman-Wilson
  Cc: Sérgio Augusto Vianna, philipoakley, Johannes Schindelin,
	git, Michal Suchánek, newren, brian m. carlson,
	Simon Pieters, stolee

[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:

>    src_branch = *ancestor ? ancestor : branch;
>    if (!strcmp(src_branch, "HEAD"))
>        src_branch = "master";

They then claim that this usage of master is

> Probably because BitKeeper uses "master" for its main branch"

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:
>
> > MASTER IS NOT INHERENTLY RELATED TO MASTER-SLAVE RELATIONS.
>
> 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:
> >
> > 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.
> >

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-15  3:52                     ` Andrew Ardill
@ 2020-06-15  4:45                       ` J. Paul Reed
  2020-06-15  5:19                         ` Andrew Ardill
  0 siblings, 1 reply; 151+ messages in thread
From: J. Paul Reed @ 2020-06-15  4:45 UTC (permalink / raw)
  To: Andrew Ardill
  Cc: Don Goodman-Wilson, Sérgio Augusto Vianna, philipoakley,
	Johannes Schindelin, git, Michal Suchánek, newren,
	brian m. carlson, Simon Pieters, stolee


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]

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

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

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

Oops.

> It's just as likely that the 'master' usage was common in the industry

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

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

See above.

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

Cool. Sounds like we mostly agree...

-p
-- 
J. Paul Reed
https://jpaulreed.com
PGP: 0xDF8708F8


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-15  4:45                       ` J. Paul Reed
@ 2020-06-15  5:19                         ` Andrew Ardill
  0 siblings, 0 replies; 151+ messages in thread
From: Andrew Ardill @ 2020-06-15  5:19 UTC (permalink / raw)
  To: J. Paul Reed
  Cc: Don Goodman-Wilson, Sérgio Augusto Vianna, philipoakley,
	Johannes Schindelin, git, Michal Suchánek, newren,
	brian m. carlson, Simon Pieters, stolee

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

On Mon, 15 Jun 2020 at 14:45, J. Paul Reed <preed@sigkill.com> wrote:
> Heya Andrew... turns out I read this list too, so... thanks for referencin'
> all my work!

No problem, I appreciated the effort you went to.

> > 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,
>
> https://marc.info/?l=git&m=111968031816936&w=2

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.

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

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.

> Oops.
>
> > It's just as likely that the 'master' usage was common in the industry
>
> Do you have any specific references to, specifically, common usage in the
> industry, at that time?

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!)

> > 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.
>
> See above.
>
> > 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.
>
> Cool. Sounds like we mostly agree...

Cool indeed :)

Regards,

Andrew Ardill

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  2:59             ` Johannes Schindelin
@ 2020-06-15 10:07               ` Michal Suchánek
  0 siblings, 0 replies; 151+ messages in thread
From: Michal Suchánek @ 2020-06-15 10:07 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Junio C Hamano, Derrick Stolee, Don Goodman-Wilson,
	brian m. carlson, Simon Pieters, git

On Sun, Jun 14, 2020 at 04:59:32AM +0200, Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 11 Jun 2020, Junio C Hamano wrote:
> 
> > Derrick Stolee <stolee@gmail.com> writes:
> >
> > > On 6/11/2020 7:59 AM, Don Goodman-Wilson wrote:
> > >> On Thu, Jun 11, 2020 at 1:52 PM Michal Suchánek <msuchanek@suse.de> 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.
> > >>
> > >> I _really_ like this idea (and your reasoning). Seconded.
> > >
> > > Yes, adding a -b|--branch option would be an excellent addition to
> > > the config option.
> >
> > 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.
> 
> I agree, and I incorporated this already in the latest version I pushed to
> https://github.com/gitgitgadget/git/pull/656.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (7 preceding siblings ...)
  2020-06-15  0:02 ` Sérgio Augusto Vianna
@ 2020-06-15 14:39 ` Sérgio Augusto Vianna
  2020-06-15 14:39 ` Sérgio Augusto Vianna
                   ` (5 subsequent siblings)
  14 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-15 14:39 UTC (permalink / raw)
  To: simon; +Cc: git

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (8 preceding siblings ...)
  2020-06-15 14:39 ` Sérgio Augusto Vianna
@ 2020-06-15 14:39 ` Sérgio Augusto Vianna
  2020-06-15 23:15 ` Sérgio Augusto Vianna
                   ` (4 subsequent siblings)
  14 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-15 14:39 UTC (permalink / raw)
  To: simon; +Cc: git

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 12:20                 ` Sérgio Augusto Vianna
  2020-06-14 13:58                   ` Don Goodman-Wilson
  2020-06-14 18:19                   ` Konstantin Ryabitsev
@ 2020-06-15 18:07                   ` Jonathan Nieder
  2020-06-15 18:18                     ` Sérgio Augusto Vianna
  2 siblings, 1 reply; 151+ messages in thread
From: Jonathan Nieder @ 2020-06-15 18:07 UTC (permalink / raw)
  To: Sérgio Augusto Vianna
  Cc: philipoakley, Johannes.Schindelin, don, git, msuchanek, newren,
	sandals, simon, stolee

Sérgio Augusto Vianna wrote:

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-15 18:07                   ` Jonathan Nieder
@ 2020-06-15 18:18                     ` Sérgio Augusto Vianna
       [not found]                       ` <CAAwdEzDgJuoQJAZsrT0piuZPVP6nJTSB9RCbcuXO03-BYTnmOQ@mail.gmail.com>
  0 siblings, 1 reply; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-15 18:18 UTC (permalink / raw)
  To: jrnieder
  Cc: Johannes.Schindelin, don, git, msuchanek, newren, philipoakley,
	sandals, sergio.a.vianna, simon, stolee

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
       [not found]                       ` <CAAwdEzDgJuoQJAZsrT0piuZPVP6nJTSB9RCbcuXO03-BYTnmOQ@mail.gmail.com>
@ 2020-06-15 19:37                         ` Sérgio Augusto Vianna
  2020-06-15 19:50                           ` Alexandru Pătrănescu
  2020-06-15 20:42                           ` Randall S. Becker
  0 siblings, 2 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-15 19:37 UTC (permalink / raw)
  To: Alexandru Pătrănescu
  Cc: jrnieder, johannes.schindelin, don, git, msuchanek, newren,
	philipoakley, sandals, simon, stolee

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-15 19:37                         ` Sérgio Augusto Vianna
@ 2020-06-15 19:50                           ` Alexandru Pătrănescu
  2020-06-15 20:44                             ` Elijah Newren
  2020-06-15 20:42                           ` Randall S. Becker
  1 sibling, 1 reply; 151+ messages in thread
From: Alexandru Pătrănescu @ 2020-06-15 19:50 UTC (permalink / raw)
  To: Sérgio Augusto Vianna
  Cc: jrnieder, johannes.schindelin, don, git, msuchanek, newren,
	philipoakley, sandals, simon, stolee

Sérgio
On Mon, Jun 15, 2020 at 10:37 PM Sérgio Augusto Vianna
<sergio.a.vianna@gmail.com> wrote:
>
>  >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?
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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* RE: Rename offensive terminology (master)
  2020-06-15 19:37                         ` Sérgio Augusto Vianna
  2020-06-15 19:50                           ` Alexandru Pătrănescu
@ 2020-06-15 20:42                           ` Randall S. Becker
  1 sibling, 0 replies; 151+ messages in thread
From: Randall S. Becker @ 2020-06-15 20:42 UTC (permalink / raw)
  To: 'Sérgio Augusto Vianna',
	'Alexandru Pătrănescu'
  Cc: jrnieder, johannes.schindelin, don, git, msuchanek, newren,
	philipoakley, sandals, simon, stolee

On June 15, 2020 3:38 PM, Sérgio Augusto Vianna wrote:
> Subject: Re: Rename offensive terminology (master)
>  >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?

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-15 19:50                           ` Alexandru Pătrănescu
@ 2020-06-15 20:44                             ` Elijah Newren
  0 siblings, 0 replies; 151+ messages in thread
From: Elijah Newren @ 2020-06-15 20:44 UTC (permalink / raw)
  To: Alexandru Pătrănescu
  Cc: Jonathan Nieder, Johannes Schindelin, Don Goodman-Wilson,
	Git Mailing List, Michal Suchánek, Philip Oakley,
	brian m. carlson, Simon Pieters, Derrick Stolee,
	Sérgio Augusto Vianna

On Mon, Jun 15, 2020 at 12:51 PM Alexandru Pătrănescu
<drealecs@gmail.com> wrote:
>
> Sérgio
> On Mon, Jun 15, 2020 at 10:37 PM Sérgio Augusto Vianna
> <sergio.a.vianna@gmail.com> wrote:
> >
> >  >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?
> 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 :)

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10 21:30   ` Johannes Schindelin
                       ` (3 preceding siblings ...)
  2020-06-15  0:34     ` James Ramsay
@ 2020-06-15 21:38     ` Elijah Newren
  2020-06-15 21:46       ` Elijah Newren
  2020-06-16 21:07     ` ZeeVriend
  5 siblings, 1 reply; 151+ messages in thread
From: Elijah Newren @ 2020-06-15 21:38 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: brian m. carlson, Simon Pieters, Don Goodman-Wilson, Git Mailing List

Hi,

On Wed, Jun 10, 2020 at 2:34 PM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> 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`.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-15 21:38     ` Elijah Newren
@ 2020-06-15 21:46       ` Elijah Newren
  0 siblings, 0 replies; 151+ messages in thread
From: Elijah Newren @ 2020-06-15 21:46 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: brian m. carlson, Simon Pieters, Don Goodman-Wilson, Git Mailing List

A quick clarification:

On Mon, Jun 15, 2020 at 2:38 PM Elijah Newren <newren@gmail.com> wrote:
>
> 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?

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (9 preceding siblings ...)
  2020-06-15 14:39 ` Sérgio Augusto Vianna
@ 2020-06-15 23:15 ` Sérgio Augusto Vianna
  2020-06-16  1:00 ` Fang-Pen Lin
                   ` (3 subsequent siblings)
  14 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-15 23:15 UTC (permalink / raw)
  To: simon; +Cc: git

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (10 preceding siblings ...)
  2020-06-15 23:15 ` Sérgio Augusto Vianna
@ 2020-06-16  1:00 ` Fang-Pen Lin
  2020-06-16  1:38 ` Sérgio Augusto Vianna
                   ` (2 subsequent siblings)
  14 siblings, 0 replies; 151+ messages in thread
From: Fang-Pen Lin @ 2020-06-16  1:00 UTC (permalink / raw)
  To: simon; +Cc: git, Fang-Pen Lin

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

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

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

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.

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (11 preceding siblings ...)
  2020-06-16  1:00 ` Fang-Pen Lin
@ 2020-06-16  1:38 ` Sérgio Augusto Vianna
  2020-06-21 19:50 ` Social Justice Movements [was: Rename offensive terminology (master)] Luke Kenneth Casson Leighton
  2020-06-23 23:21 ` Rename offensive terminology (master) Gunnar Liljas
  14 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-16  1:38 UTC (permalink / raw)
  To: simon; +Cc: git


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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  6:32               ` Don Goodman-Wilson
  2020-06-14  6:34                 ` Don Goodman-Wilson
@ 2020-06-16  7:31                 ` demerphq
  2020-06-16  8:38                   ` Oleg
  1 sibling, 1 reply; 151+ messages in thread
From: demerphq @ 2020-06-16  7:31 UTC (permalink / raw)
  To: Don Goodman-Wilson
  Cc: Sérgio Augusto Vianna, Junio C Hamano, Git,
	brian m. carlson, Simon Pieters

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

Well said sir. I might quote that sometime.

Cheers,
Yves

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 18:23                     ` Sérgio Augusto Vianna
  2020-06-14 19:04                       ` Konstantin Ryabitsev
  2020-06-14 20:41                       ` Philip Oakley
@ 2020-06-16  7:36                       ` demerphq
  2020-06-16  7:43                         ` Michal Suchánek
  2 siblings, 1 reply; 151+ messages in thread
From: demerphq @ 2020-06-16  7:36 UTC (permalink / raw)
  To: Sérgio Augusto Vianna
  Cc: konstantin, Johannes Schindelin, don, Git, msuchanek, newren,
	philipoakley, brian m. carlson, Simon Pieters, Derrick Stolee

On Sun, 14 Jun 2020 at 20:24, Sérgio Augusto Vianna
<sergio.a.vianna@gmail.com> wrote:
>
> Ok, can you show me a single instance where "master" was confusing or
> not descriptive enough?

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16  7:36                       ` demerphq
@ 2020-06-16  7:43                         ` Michal Suchánek
  2020-06-16  8:01                           ` demerphq
  0 siblings, 1 reply; 151+ messages in thread
From: Michal Suchánek @ 2020-06-16  7:43 UTC (permalink / raw)
  To: demerphq
  Cc: Sérgio Augusto Vianna, konstantin, Johannes Schindelin, don,
	Git, newren, philipoakley, brian m. carlson, Simon Pieters,
	Derrick Stolee

On Tue, Jun 16, 2020 at 09:36:59AM +0200, demerphq wrote:
> On Sun, 14 Jun 2020 at 20:24, Sérgio Augusto Vianna
> <sergio.a.vianna@gmail.com> wrote:
> >
> > Ok, can you show me a single instance where "master" was confusing or
> > not descriptive enough?
> 
> 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?"
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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16  7:43                         ` Michal Suchánek
@ 2020-06-16  8:01                           ` demerphq
  2020-06-16  8:59                             ` Michal Suchánek
  2020-06-17 19:56                             ` Junio C Hamano
  0 siblings, 2 replies; 151+ messages in thread
From: demerphq @ 2020-06-16  8:01 UTC (permalink / raw)
  To: Michal Suchánek
  Cc: Sérgio Augusto Vianna, konstantin, Johannes Schindelin, don,
	Git, newren, philipoakley, brian m. carlson, Simon Pieters,
	Derrick Stolee

On Tue, 16 Jun 2020 at 09:43, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Tue, Jun 16, 2020 at 09:36:59AM +0200, demerphq wrote:
> > On Sun, 14 Jun 2020 at 20:24, Sérgio Augusto Vianna
> > <sergio.a.vianna@gmail.com> wrote:
> > >
> > > Ok, can you show me a single instance where "master" was confusing or
> > > not descriptive enough?
> >
> > 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?"
> 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.

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


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16  7:31                 ` demerphq
@ 2020-06-16  8:38                   ` Oleg
  2020-06-16 19:33                     ` Elijah Newren
  0 siblings, 1 reply; 151+ messages in thread
From: Oleg @ 2020-06-16  8:38 UTC (permalink / raw)
  To: Git

On Tue, Jun 16, 2020 at 09:31:43AM +0200, demerphq wrote:
> On Sun, 14 Jun 2020 at 08:35, Don Goodman-Wilson <don@goodman-wilson.com> wrote:
> > 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.
> 
> Well said sir. I might quote that sometime.

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?

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-09 15:16   ` Simon Pieters
                       ` (2 preceding siblings ...)
  2020-06-09 22:36     ` brian m. carlson
@ 2020-06-16  8:50     ` Michal Suchánek
  3 siblings, 0 replies; 151+ messages in thread
From: Michal Suchánek @ 2020-06-16  8:50 UTC (permalink / raw)
  To: Simon Pieters; +Cc: brian m. carlson, git, don

Hello,

On Tue, Jun 09, 2020 at 05:16:57PM +0200, Simon Pieters wrote:
> 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

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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16  8:01                           ` demerphq
@ 2020-06-16  8:59                             ` Michal Suchánek
  2020-06-17 19:56                             ` Junio C Hamano
  1 sibling, 0 replies; 151+ messages in thread
From: Michal Suchánek @ 2020-06-16  8:59 UTC (permalink / raw)
  To: demerphq
  Cc: Sérgio Augusto Vianna, konstantin, Johannes Schindelin, don,
	Git, newren, philipoakley, brian m. carlson, Simon Pieters,
	Derrick Stolee

On Tue, Jun 16, 2020 at 10:01:54AM +0200, demerphq wrote:
> On Tue, 16 Jun 2020 at 09:43, Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > On Tue, Jun 16, 2020 at 09:36:59AM +0200, demerphq wrote:
> > > On Sun, 14 Jun 2020 at 20:24, Sérgio Augusto Vianna
> > > <sergio.a.vianna@gmail.com> wrote:
> > > >
> > > > Ok, can you show me a single instance where "master" was confusing or
> > > > not descriptive enough?
> > >
> > > 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?"
> > 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.
> 
> I think you missed my point entirely. Sergio asked how "master" might
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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14  0:50             ` Sérgio Augusto Vianna
  2020-06-14  6:32               ` Don Goodman-Wilson
@ 2020-06-16 10:04               ` Alex Smith
  2020-06-16 11:29                 ` Konstantin Tokarev
       [not found]                 ` <c0c2d9ad-1d67-8ebe-0063-524005ca97fe@whinis.com>
  1 sibling, 2 replies; 151+ messages in thread
From: Alex Smith @ 2020-06-16 10:04 UTC (permalink / raw)
  To: sergio.a.vianna; +Cc: don, git, gitster, sandals, simon

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 10:04               ` Alex Smith
@ 2020-06-16 11:29                 ` Konstantin Tokarev
  2020-06-16 11:39                   ` Robert P. J. Day
                                     ` (2 more replies)
       [not found]                 ` <c0c2d9ad-1d67-8ebe-0063-524005ca97fe@whinis.com>
  1 sibling, 3 replies; 151+ messages in thread
From: Konstantin Tokarev @ 2020-06-16 11:29 UTC (permalink / raw)
  To: Alex Smith, sergio.a.vianna; +Cc: don, git, gitster, sandals, simon



16.06.2020, 13:31, "Alex Smith" <alexsmith@gmail.com>:
> 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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
       [not found]                 ` <c0c2d9ad-1d67-8ebe-0063-524005ca97fe@whinis.com>
@ 2020-06-16 11:38                   ` Whinis
  2020-06-16 12:16                     ` Oleg
  2020-06-16 13:30                     ` Konstantin Ryabitsev
  0 siblings, 2 replies; 151+ messages in thread
From: Whinis @ 2020-06-16 11:38 UTC (permalink / raw)
  To: alexsmith; +Cc: don, git, gitster, sandals, sergio.a.vianna, simon

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 11:29                 ` Konstantin Tokarev
@ 2020-06-16 11:39                   ` Robert P. J. Day
  2020-06-16 11:39                   ` Oleg
  2020-06-17  7:27                   ` Sergey Organov
  2 siblings, 0 replies; 151+ messages in thread
From: Robert P. J. Day @ 2020-06-16 11:39 UTC (permalink / raw)
  To: Konstantin Tokarev
  Cc: Alex Smith, sergio.a.vianna, don, git, gitster, sandals, simon

On Tue, 16 Jun 2020, Konstantin Tokarev wrote:

>
>
> 16.06.2020, 13:31, "Alex Smith" <alexsmith@gmail.com>:
> > 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.
>
> I guess their next move might be to force sound engineers to rename
> master channel and derived term "mastering" into something more
> politically correct.

  nicely done ... a masterstroke of rhetoric.

  damn it ...

rday

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 11:29                 ` Konstantin Tokarev
  2020-06-16 11:39                   ` Robert P. J. Day
@ 2020-06-16 11:39                   ` Oleg
  2020-06-17  7:27                   ` Sergey Organov
  2 siblings, 0 replies; 151+ messages in thread
From: Oleg @ 2020-06-16 11:39 UTC (permalink / raw)
  To: git

On Tue, Jun 16, 2020 at 02:29:49PM +0300, Konstantin Tokarev wrote:
> I guess their next move might be to force sound engineers to rename master channel and
> derived term "mastering" into something more politically correct.

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 11:38                   ` Whinis
@ 2020-06-16 12:16                     ` Oleg
  2020-06-16 13:30                     ` Konstantin Ryabitsev
  1 sibling, 0 replies; 151+ messages in thread
From: Oleg @ 2020-06-16 12:16 UTC (permalink / raw)
  To: git

On Tue, Jun 16, 2020 at 07:38:33AM -0400, Whinis wrote:
> > 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.
> 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.

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.

> 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

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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 11:38                   ` Whinis
  2020-06-16 12:16                     ` Oleg
@ 2020-06-16 13:30                     ` Konstantin Ryabitsev
  2020-06-16 13:55                       ` John Turner
                                         ` (2 more replies)
  1 sibling, 3 replies; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-16 13:30 UTC (permalink / raw)
  To: Whinis; +Cc: alexsmith, don, git, gitster, sandals, sergio.a.vianna, simon

On Tue, Jun 16, 2020 at 07:38:33AM -0400, Whinis wrote:
> > 
> > This sickens me.
> 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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 13:30                     ` Konstantin Ryabitsev
@ 2020-06-16 13:55                       ` John Turner
  2020-06-16 14:14                         ` Michal Suchánek
  2020-06-16 15:49                         ` Konstantin Ryabitsev
  2020-06-16 14:24                       ` Sérgio Augusto Vianna
  2020-06-16 14:27                       ` Oleg
  2 siblings, 2 replies; 151+ messages in thread
From: John Turner @ 2020-06-16 13:55 UTC (permalink / raw)
  To: konstantin
  Cc: Whinis, alexsmith, don, git, gitster, sandals, sergio.a.vianna, simon

> Let's leave emotionally charged rhetoric and discuss this like
> reasonable human beings.
That would be fine except the entire thread is started on emotionally 
charged rhetoric

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

> 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")
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?

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

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


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

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 13:55                       ` John Turner
@ 2020-06-16 14:14                         ` Michal Suchánek
  2020-06-16 14:29                           ` Whinis
  2020-06-16 16:19                           ` Alex Smith
  2020-06-16 15:49                         ` Konstantin Ryabitsev
  1 sibling, 2 replies; 151+ messages in thread
From: Michal Suchánek @ 2020-06-16 14:14 UTC (permalink / raw)
  To: John Turner
  Cc: konstantin, Whinis, alexsmith, don, git, gitster, sandals,
	sergio.a.vianna, simon

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

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 13:30                     ` Konstantin Ryabitsev
  2020-06-16 13:55                       ` John Turner
@ 2020-06-16 14:24                       ` Sérgio Augusto Vianna
  2020-06-16 14:27                       ` Oleg
  2 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-16 14:24 UTC (permalink / raw)
  To: konstantin
  Cc: Whinis, alexsmith, don, git, gitster, sandals, sergio.a.vianna, simon

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 13:30                     ` Konstantin Ryabitsev
  2020-06-16 13:55                       ` John Turner
  2020-06-16 14:24                       ` Sérgio Augusto Vianna
@ 2020-06-16 14:27                       ` Oleg
  2020-06-16 16:03                         ` Konstantin Ryabitsev
  2 siblings, 1 reply; 151+ messages in thread
From: Oleg @ 2020-06-16 14:27 UTC (permalink / raw)
  To: git

On Tue, Jun 16, 2020 at 09:30:54AM -0400, Konstantin Ryabitsev wrote:
> Let's leave emotionally charged rhetoric and discuss this like 
> reasonable human beings.

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

> Here are facts:
> 2. Branch naming is entirely the choice of individual repository 
>    maintainers. Some prefer not to have a "master" branch, and it's not

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

>    simply because of "political correctness" reasons as everyone 
>    insists:

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?

>    - they may prefer to have "stable" and "development" branches

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

>    - they may want to use localized names for all their naming 
>      conventions (using Cyrillic, Hanzi, Kana, whatever)

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.

>    - they may be goofing off (there's a furry-related repository on 
>      GitHub with the main branch called "yiffed")

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

> 3. In your example, "millions and billions" of scripts are already wrong 
>    if they assume that there is always a "master" branch. However, it

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.

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

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 14:14                         ` Michal Suchánek
@ 2020-06-16 14:29                           ` Whinis
  2020-06-16 16:19                           ` Alex Smith
  1 sibling, 0 replies; 151+ messages in thread
From: Whinis @ 2020-06-16 14:29 UTC (permalink / raw)
  To: msuchanek
  Cc: alexsmith, don, git, gitster, konstantin, sandals,
	sergio.a.vianna, simon

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


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 13:55                       ` John Turner
  2020-06-16 14:14                         ` Michal Suchánek
@ 2020-06-16 15:49                         ` Konstantin Ryabitsev
  2020-06-16 16:09                           ` Whinis
  1 sibling, 1 reply; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-16 15:49 UTC (permalink / raw)
  To: John Turner
  Cc: Whinis, alexsmith, don, git, gitster, sandals, sergio.a.vianna, simon

On Tue, Jun 16, 2020 at 09:55:29AM -0400, John Turner wrote:
> 
> > 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.
> 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.

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.

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

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

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

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.

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

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.

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

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

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

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.

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

Nobody is preventing you from being that person.

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 14:27                       ` Oleg
@ 2020-06-16 16:03                         ` Konstantin Ryabitsev
  2020-06-16 17:27                           ` Oleg
  0 siblings, 1 reply; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-16 16:03 UTC (permalink / raw)
  To: Oleg; +Cc: git

On Tue, Jun 16, 2020 at 05:27:01PM +0300, Oleg wrote:
> 
> > Here are facts:
> > 2. Branch naming is entirely the choice of individual repository 
> >    maintainers. Some prefer not to have a "master" branch, and it's not
> 
> Some :-)? This "some" are very few people/projects and no one of them have
> serious reasons to do it(it pampering).

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.

> >    simply because of "political correctness" reasons as everyone 
> >    insists:
> 
> 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?

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

> >    - they may want to use localized names for all their naming 
> >    conventions (using Cyrillic, Hanzi, Kana, whatever)
> 
> 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.

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?

> > 3. In your example, "millions and billions" of scripts are already wrong 
> >    if they assume that there is always a "master" branch. However, it
> 
> 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.

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.

> > 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.
> 
> We have so little problems and difficulties, that yet another one willn't
> make our life more hard.

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

-K

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 15:49                         ` Konstantin Ryabitsev
@ 2020-06-16 16:09                           ` Whinis
  0 siblings, 0 replies; 151+ messages in thread
From: Whinis @ 2020-06-16 16:09 UTC (permalink / raw)
  To: alexsmith, don, git, gitster, sandals, sergio.a.vianna, simon


On 6/16/2020 11:49 AM, Konstantin Ryabitsev wrote:
> On Tue, Jun 16, 2020 at 09:55:29AM -0400, John Turner wrote:
>>> 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.
>> 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.
> 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.
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?
>> 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?
> It doesn't work perfectly. The goal is to improve it so it does.
>
>> 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.
> 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.
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.
>> 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.
> 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.
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.
>> 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.
> "Entirely retool" is not a fair statement for "set a single config value
> in a single file".

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.

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

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?

>> 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.
> Nobody is preventing you from being that person.
Then consider me that person.
>> I leave with this, if we are to leave out the emotions what good
>> reason is there to push through this change?
> 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.
You yourself have admitted its already possible to have an arbitrary 
collection of branches, so what does this change?

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 14:14                         ` Michal Suchánek
  2020-06-16 14:29                           ` Whinis
@ 2020-06-16 16:19                           ` Alex Smith
  1 sibling, 0 replies; 151+ messages in thread
From: Alex Smith @ 2020-06-16 16:19 UTC (permalink / raw)
  To: msuchanek
  Cc: Whinis, alexsmith, don, git, gitster, konstantin, sandals,
	sergio.a.vianna, simon, whinis


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

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 16:03                         ` Konstantin Ryabitsev
@ 2020-06-16 17:27                           ` Oleg
  2020-06-16 17:42                             ` Konstantin Ryabitsev
  0 siblings, 1 reply; 151+ messages in thread
From: Oleg @ 2020-06-16 17:27 UTC (permalink / raw)
  To: git

On Tue, Jun 16, 2020 at 12:03:49PM -0400, Konstantin Ryabitsev 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.

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

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

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

> > 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.
> 
> 1C scripting language is written entirely in Russian. Many official

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

> Russian sites use .рф domain names. If someone wants to make all their 
> branch names in Cyrillic, why should we prevent them from doing so?

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

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

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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 17:27                           ` Oleg
@ 2020-06-16 17:42                             ` Konstantin Ryabitsev
  2020-06-16 18:35                               ` Sergey Lapin
  2020-06-16 19:03                               ` Oleg
  0 siblings, 2 replies; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-16 17:42 UTC (permalink / raw)
  To: Oleg; +Cc: git

On Tue, Jun 16, 2020 at 08:27:49PM +0300, Oleg wrote:
> > Russian sites use .рф domain names. If someone wants to make all 
> > their branch names in Cyrillic, why should we prevent them from 
> > doing so?
> 
> Because there are no such people. You try to fix non-existent problem.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 17:42                             ` Konstantin Ryabitsev
@ 2020-06-16 18:35                               ` Sergey Lapin
  2020-06-16 19:03                               ` Oleg
  1 sibling, 0 replies; 151+ messages in thread
From: Sergey Lapin @ 2020-06-16 18:35 UTC (permalink / raw)
  To: Oleg, git

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 08:27:49PM +0300, Oleg wrote:
> > > Russian sites use .рф domain names. If someone wants to make all
> > > their branch names in Cyrillic, why should we prevent them from
> > > doing so?
> >
> > Because there are no such people. You try to fix non-existent problem.
>
> 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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 17:42                             ` Konstantin Ryabitsev
  2020-06-16 18:35                               ` Sergey Lapin
@ 2020-06-16 19:03                               ` Oleg
  1 sibling, 0 replies; 151+ messages in thread
From: Oleg @ 2020-06-16 19:03 UTC (permalink / raw)
  To: git

On Tue, Jun 16, 2020 at 01:42:06PM -0400, Konstantin Ryabitsev wrote:
> > Because there are no such people. You try to fix non-existent problem.
> 
> 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.

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

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

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16  8:38                   ` Oleg
@ 2020-06-16 19:33                     ` Elijah Newren
  2020-06-17  1:17                       ` Sergey Lapin
  2020-06-17  7:45                       ` Oleg
  0 siblings, 2 replies; 151+ messages in thread
From: Elijah Newren @ 2020-06-16 19:33 UTC (permalink / raw)
  To: Oleg; +Cc: Git

On Tue, Jun 16, 2020 at 1:39 AM Oleg <lego_12239@rambler.ru> wrote:
>
> On Tue, Jun 16, 2020 at 09:31:43AM +0200, demerphq wrote:
> > On Sun, 14 Jun 2020 at 08:35, Don Goodman-Wilson <don@goodman-wilson.com> wrote:
> > > 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.
> >
> > Well said sir. I might quote that sometime.

...
> The stupid idea.
> The stupid discussion.
> All world use this terminology and it disturb nobody with sane mind.
...
> Because someone is completely mad...
> Fucking hypocrites.
> Are you all really so stupid?
> Just do it and feel better, liers.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-10 21:30   ` Johannes Schindelin
                       ` (4 preceding siblings ...)
  2020-06-15 21:38     ` Elijah Newren
@ 2020-06-16 21:07     ` ZeeVriend
  2020-06-17  7:49       ` Oleg
  5 siblings, 1 reply; 151+ messages in thread
From: ZeeVriend @ 2020-06-16 21:07 UTC (permalink / raw)
  To: johannes.schindelin, Johannes.Schindelin
  Cc: don, git, sandals, simon, zeevriend

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!

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 19:33                     ` Elijah Newren
@ 2020-06-17  1:17                       ` Sergey Lapin
  2020-06-17  7:45                       ` Oleg
  1 sibling, 0 replies; 151+ messages in thread
From: Sergey Lapin @ 2020-06-17  1:17 UTC (permalink / raw)
  To: Elijah Newren; +Cc: Oleg, Git

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 1:39 AM Oleg <lego_12239@rambler.ru> wrote:
> >
> > On Tue, Jun 16, 2020 at 09:31:43AM +0200, demerphq wrote:
> > > On Sun, 14 Jun 2020 at 08:35, Don Goodman-Wilson <don@goodman-wilson.com> wrote:
> > > > 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.
> > >
> > > Well said sir. I might quote that sometime.
>
> ...
> > The stupid idea.
> > The stupid discussion.
> > All world use this terminology and it disturb nobody with sane mind.
> ...
> > Because someone is completely mad...
> > Fucking hypocrites.
> > Are you all really so stupid?
> > Just do it and feel better, liers.
>
> 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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 11:29                 ` Konstantin Tokarev
  2020-06-16 11:39                   ` Robert P. J. Day
  2020-06-16 11:39                   ` Oleg
@ 2020-06-17  7:27                   ` Sergey Organov
  2 siblings, 0 replies; 151+ messages in thread
From: Sergey Organov @ 2020-06-17  7:27 UTC (permalink / raw)
  To: Konstantin Tokarev
  Cc: Alex Smith, sergio.a.vianna, don, git, gitster, sandals, simon

Konstantin Tokarev <annulen@yandex.ru> writes:

> 16.06.2020, 13:31, "Alex Smith" <alexsmith@gmail.com>:
>> 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.
>
> I guess their next move might be to force sound engineers to rename
> master channel and derived term "mastering" into something more
> politically correct.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 19:33                     ` Elijah Newren
  2020-06-17  1:17                       ` Sergey Lapin
@ 2020-06-17  7:45                       ` Oleg
  1 sibling, 0 replies; 151+ messages in thread
From: Oleg @ 2020-06-17  7:45 UTC (permalink / raw)
  To: Git

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

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.

> 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

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

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

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?


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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 21:07     ` ZeeVriend
@ 2020-06-17  7:49       ` Oleg
  2020-06-17 20:48         ` ZeeVriend
  2020-06-17 20:52         ` ZeeVriend
  0 siblings, 2 replies; 151+ messages in thread
From: Oleg @ 2020-06-17  7:49 UTC (permalink / raw)
  To: git

On Tue, Jun 16, 2020 at 11:07:01PM +0200, ZeeVriend wrote:
> 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

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


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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-14 13:58                   ` Don Goodman-Wilson
  2020-06-14 14:05                     ` Sérgio Augusto Vianna
  2020-06-15  3:52                     ` Andrew Ardill
@ 2020-06-17  8:27                     ` Michal Suchánek
  2 siblings, 0 replies; 151+ messages in thread
From: Michal Suchánek @ 2020-06-17  8:27 UTC (permalink / raw)
  To: Don Goodman-Wilson
  Cc: Sérgio Augusto Vianna, philipoakley, Johannes Schindelin,
	git, newren, brian m. carlson, Simon Pieters, stolee

On Sun, Jun 14, 2020 at 03:58:33PM +0200, Don Goodman-Wilson wrote:
> > MASTER IS NOT INHERENTLY RELATED TO MASTER-SLAVE RELATIONS.
> 
> 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
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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16  8:01                           ` demerphq
  2020-06-16  8:59                             ` Michal Suchánek
@ 2020-06-17 19:56                             ` Junio C Hamano
  2020-06-17 20:10                               ` Jonathan Nieder
  2020-06-18  7:40                               ` demerphq
  1 sibling, 2 replies; 151+ messages in thread
From: Junio C Hamano @ 2020-06-17 19:56 UTC (permalink / raw)
  To: demerphq
  Cc: Michal Suchánek, Sérgio Augusto Vianna, konstantin,
	Johannes Schindelin, don, Git, newren, philipoakley,
	brian m. carlson, Simon Pieters, Derrick Stolee

demerphq <demerphq@gmail.com> writes:

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

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

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

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?



^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-17 19:56                             ` Junio C Hamano
@ 2020-06-17 20:10                               ` Jonathan Nieder
  2020-06-17 20:17                                 ` Jonathan Nieder
  2020-06-18  7:40                               ` demerphq
  1 sibling, 1 reply; 151+ messages in thread
From: Jonathan Nieder @ 2020-06-17 20:10 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: demerphq, Michal Suchánek, Sérgio Augusto Vianna,
	konstantin, Johannes Schindelin, don, Git, newren, philipoakley,
	brian m. carlson, Simon Pieters, Derrick Stolee

Hi,

Junio C Hamano wrote:
> demerphq <demerphq@gmail.com> writes:

>> 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."
>
> Hmph, why isn't the last one "trunk trunk"?
>
>> Similarly when the perl project migrated to git we renamed "master" to
>> "blead" to reduce the possibility "master master" confusion.
>
> 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?

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-17 20:10                               ` Jonathan Nieder
@ 2020-06-17 20:17                                 ` Jonathan Nieder
  2020-06-18  7:57                                   ` demerphq
  0 siblings, 1 reply; 151+ messages in thread
From: Jonathan Nieder @ 2020-06-17 20:17 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: demerphq, Michal Suchánek, Sérgio Augusto Vianna,
	konstantin, Johannes Schindelin, don, Git, newren, philipoakley,
	brian m. carlson, Simon Pieters, Derrick Stolee

Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> demerphq <demerphq@gmail.com> writes:

>>> 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."
>>
>> Hmph, why isn't the last one "trunk 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?
>
> 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.
[...]
> In particular when building distributed systems, historically it has
> been common to have one of the components being built be named
> 'master'.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-17  7:49       ` Oleg
@ 2020-06-17 20:48         ` ZeeVriend
  2020-06-18  8:28           ` Oleg
  2020-06-17 20:52         ` ZeeVriend
  1 sibling, 1 reply; 151+ messages in thread
From: ZeeVriend @ 2020-06-17 20:48 UTC (permalink / raw)
  To: lego_12239; +Cc: git, Zee Vriend

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!

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-17  7:49       ` Oleg
  2020-06-17 20:48         ` ZeeVriend
@ 2020-06-17 20:52         ` ZeeVriend
  1 sibling, 0 replies; 151+ messages in thread
From: ZeeVriend @ 2020-06-17 20:52 UTC (permalink / raw)
  To: lego_12239; +Cc: git, Zee Vriend

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!

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-17 19:56                             ` Junio C Hamano
  2020-06-17 20:10                               ` Jonathan Nieder
@ 2020-06-18  7:40                               ` demerphq
  2020-06-18 18:04                                 ` Junio C Hamano
  1 sibling, 1 reply; 151+ messages in thread
From: demerphq @ 2020-06-18  7:40 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Michal Suchánek, Sérgio Augusto Vianna, konstantin,
	Johannes Schindelin, Don Goodman-Wilson, Git, newren,
	philipoakley, brian m. carlson, Simon Pieters, Derrick Stolee

On Wed, 17 Jun 2020 at 21:56, Junio C Hamano <gitster@pobox.com> wrote:
>
> demerphq <demerphq@gmail.com> writes:
>
> > 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."
>
> Hmph, why isn't the last one "trunk trunk"?

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.

> > Similarly when the perl project migrated to git we renamed "master" to
> > "blead" to reduce the possibility "master master" confusion.
>
> 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'.

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

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

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.

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

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/

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-17 20:17                                 ` Jonathan Nieder
@ 2020-06-18  7:57                                   ` demerphq
  2020-06-18  8:38                                     ` Oleg
  2020-06-18 15:23                                     ` Konstantin Ryabitsev
  0 siblings, 2 replies; 151+ messages in thread
From: demerphq @ 2020-06-18  7:57 UTC (permalink / raw)
  To: Jonathan Nieder
  Cc: Junio C Hamano, Michal Suchánek, Sérgio Augusto Vianna,
	Konstantin Ryabitsev, Johannes Schindelin, Don Goodman-Wilson,
	Git, newren, philipoakley, brian m. carlson, Simon Pieters,
	Derrick Stolee

On Wed, 17 Jun 2020 at 22:17, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Jonathan Nieder wrote:
> > Junio C Hamano wrote:
> >> demerphq <demerphq@gmail.com> writes:
>
> >>> 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."
> >>
> >> Hmph, why isn't the last one "trunk 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?
> >
> > 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.
> [...]
> > In particular when building distributed systems, historically it has
> > been common to have one of the components being built be named
> > 'master'.
>
> 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.

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


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-17 20:48         ` ZeeVriend
@ 2020-06-18  8:28           ` Oleg
  0 siblings, 0 replies; 151+ messages in thread
From: Oleg @ 2020-06-18  8:28 UTC (permalink / raw)
  To: git

On Wed, Jun 17, 2020 at 10:48:42PM +0200, ZeeVriend wrote:
> 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.

A positive meaning exist for any word ;-).

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

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

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

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.

> Let me wish you a good day and happy moments next!

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-18  7:57                                   ` demerphq
@ 2020-06-18  8:38                                     ` Oleg
  2020-06-18 10:17                                       ` demerphq
  2020-06-18 15:23                                     ` Konstantin Ryabitsev
  1 sibling, 1 reply; 151+ messages in thread
From: Oleg @ 2020-06-18  8:38 UTC (permalink / raw)
  To: Git

On Thu, Jun 18, 2020 at 09:57:42AM +0200, demerphq wrote:
> 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. :-)

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

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-18  8:38                                     ` Oleg
@ 2020-06-18 10:17                                       ` demerphq
  0 siblings, 0 replies; 151+ messages in thread
From: demerphq @ 2020-06-18 10:17 UTC (permalink / raw)
  To: Oleg; +Cc: Git

On Thu, 18 Jun 2020 at 11:57, Oleg <lego_12239@rambler.ru> wrote:
>
> On Thu, Jun 18, 2020 at 09:57:42AM +0200, demerphq wrote:
> > 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. :-)
>
> The most workflow agnostic name is "branch". it is so neutral that you want to
> change it ASAP :-).

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

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-18  7:57                                   ` demerphq
  2020-06-18  8:38                                     ` Oleg
@ 2020-06-18 15:23                                     ` Konstantin Ryabitsev
  1 sibling, 0 replies; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-18 15:23 UTC (permalink / raw)
  To: demerphq
  Cc: Jonathan Nieder, Junio C Hamano, Michal Suchánek,
	Sérgio Augusto Vianna, Johannes Schindelin,
	Don Goodman-Wilson, Git, newren, philipoakley, brian m. carlson,
	Simon Pieters, Derrick Stolee

On Thu, Jun 18, 2020 at 09:57:42AM +0200, demerphq 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.
> 
> 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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-18  7:40                               ` demerphq
@ 2020-06-18 18:04                                 ` Junio C Hamano
  0 siblings, 0 replies; 151+ messages in thread
From: Junio C Hamano @ 2020-06-18 18:04 UTC (permalink / raw)
  To: demerphq
  Cc: Michal Suchánek, Sérgio Augusto Vianna, konstantin,
	Johannes Schindelin, Don Goodman-Wilson, Git, newren,
	philipoakley, brian m. carlson, Simon Pieters, Derrick Stolee

demerphq <demerphq@gmail.com> writes:

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

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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Social Justice Movements [was: Rename offensive terminology (master)]
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (12 preceding siblings ...)
  2020-06-16  1:38 ` Sérgio Augusto Vianna
@ 2020-06-21 19:50 ` Luke Kenneth Casson Leighton
  2020-06-23 23:21 ` Rename offensive terminology (master) Gunnar Liljas
  14 siblings, 0 replies; 151+ messages in thread
From: Luke Kenneth Casson Leighton @ 2020-06-21 19:50 UTC (permalink / raw)
  To: simon, git; +Cc: lkcl

From: lkcl@lkcl.net

> From: Simon Pieters @ 2020-05-04 17:20 UTC (permalink / raw)
>   To: git
> 
> "master" is an offensive term, as it can be interpreted as being
> slavery-origin terminology. See

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
                   ` (13 preceding siblings ...)
  2020-06-21 19:50 ` Social Justice Movements [was: Rename offensive terminology (master)] Luke Kenneth Casson Leighton
@ 2020-06-23 23:21 ` Gunnar Liljas
  2020-06-24  1:16   ` Whinis
  2020-06-24  8:19   ` lego_12239
  14 siblings, 2 replies; 151+ messages in thread
From: Gunnar Liljas @ 2020-06-23 23:21 UTC (permalink / raw)
  To: Simon Pieters; +Cc: git

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>:
>
> "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.
>
> --
> Simon Pieters
> Bocoup https://bocoup.com/
>
>

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-23 23:21 ` Rename offensive terminology (master) Gunnar Liljas
@ 2020-06-24  1:16   ` Whinis
  2020-06-24  8:19   ` lego_12239
  1 sibling, 0 replies; 151+ messages in thread
From: Whinis @ 2020-06-24  1:16 UTC (permalink / raw)
  To: gunnar.liljas; +Cc: git, simon

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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-23 23:21 ` Rename offensive terminology (master) Gunnar Liljas
  2020-06-24  1:16   ` Whinis
@ 2020-06-24  8:19   ` lego_12239
  2020-06-26 10:08     ` Gunnar Liljas
  1 sibling, 1 reply; 151+ messages in thread
From: lego_12239 @ 2020-06-24  8:19 UTC (permalink / raw)
  To: git

On Wed, Jun 24, 2020 at 01:21:32AM +0200, Gunnar Liljas wrote:
> 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."

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.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-24  8:19   ` lego_12239
@ 2020-06-26 10:08     ` Gunnar Liljas
  2020-06-26 10:34       ` Oleg
  0 siblings, 1 reply; 151+ messages in thread
From: Gunnar Liljas @ 2020-06-26 10:08 UTC (permalink / raw)
  To: lego_12239; +Cc: git

On Wed, Jun 24, 2020 at 10:19 AM <lego_12239@rambler.ru> 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").

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-26 10:08     ` Gunnar Liljas
@ 2020-06-26 10:34       ` Oleg
  0 siblings, 0 replies; 151+ messages in thread
From: Oleg @ 2020-06-26 10:34 UTC (permalink / raw)
  To: git

On Fri, Jun 26, 2020 at 12:08:30PM +0200, Gunnar Liljas wrote:
> On Wed, Jun 24, 2020 at 10:19 AM <lego_12239@rambler.ru> 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").
> 
> I don't think many would feel that. More like that everyone ignores

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.


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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-26 18:37 ` Neil Stoddard
@ 2020-06-29  8:59   ` Michal Suchánek
  0 siblings, 0 replies; 151+ messages in thread
From: Michal Suchánek @ 2020-06-29  8:59 UTC (permalink / raw)
  To: Neil Stoddard; +Cc: simon, don, git, gitster, sandals

On Fri, Jun 26, 2020 at 01:37:53PM -0500, Neil Stoddard wrote:
> Would it be possible to get a summary of the current state of the
> discussion?

> 4) Are the maintainers waiting for more discussion or input from the
>    community?  Are there voices you feel are yet to be heard?
https://lore.kernel.org/git/20200616210701.22924-1-zeevriend@gmail.com/

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
       [not found] <'CAOAHyQyn_ow7_nCJ+Jorr76_=1=_kuBAD1KhqReqVfRQQbmgiw@mail.gmail.com'>
@ 2020-06-26 18:37 ` Neil Stoddard
  2020-06-29  8:59   ` Michal Suchánek
  0 siblings, 1 reply; 151+ messages in thread
From: Neil Stoddard @ 2020-06-26 18:37 UTC (permalink / raw)
  To: simon; +Cc: don, git, gitster, sandals

Would it be possible to get a summary of the current state of the
discussion?

In addition to the ongoing patchset to enable setting a different
default initial branch name:

1) Are the git maintainers still considering renaming the initial
   default branch to something else?
2) If yes, is there consensus among the maintainers on the name
   'main'?
3) If yes, how will this change be rolled out?  Will the change be
   delayed to align with a breaking release?
4) Are the maintainers waiting for more discussion or input from the
   community?  Are there voices you feel are yet to be heard?

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
       [not found]   ` <CAGqqT2zFkCUTdUnzdp4oTR2cnxBpKeY-EZtxacLLVDsF8Jiekw@mail.gmail.com>
@ 2020-06-17 12:27     ` Zac McChesney
  0 siblings, 0 replies; 151+ messages in thread
From: Zac McChesney @ 2020-06-17 12:27 UTC (permalink / raw)
  To: git

Just to give my view on this (I've been following for a couple days).

I started using git in 2016 so everything I've ever done with git has
a master branch, every tutorial I've followed uses a master branch,
and everyone I've worked with since 2016 is used to using a master
branch.

I don't want to join in a political debate, and I don't see why
politics has to have any impact on non-political software, there is no
technical reason for this change that will eventually impact every
developer that uses git, which is most developers.

Git is a version control software, if someone is using git to manage a
political project, they're free to use a different branch name, but I
don't see why a backend developer working on non-political projects
should be impacted by an unnecessary breaking change.

An example scenario I can see happening (especially to inexperienced
Devs) if the default branch name is changed:

Dev gets a new laptop and installs git, all their projects work as expected.
They create a new project with "git init".
"Where's master?!" "Did I do something wrong? Every other time I've
done that it created a master branch".

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-17 11:34 Alastair Houghton
@ 2020-06-17 11:49 ` Oleg
       [not found] ` <CAGqqT2w=ntxd6RNkpy175TbgiudUSOc0tAPoDsbjv=4V+73cXw@mail.gmail.com>
  1 sibling, 0 replies; 151+ messages in thread
From: Oleg @ 2020-06-17 11:49 UTC (permalink / raw)
  To: git

On Wed, Jun 17, 2020 at 12:34:05PM +0100, Alastair Houghton wrote:
> Just to stick my oar in here, *if* it’s going to change (and I’m yet to be convinced that it should, but I’m also not opposed in principle to a different name), **PLEASE** can we change it to “trunk”, which is what most of us were using before Git became popular anyway?  That at least makes sense in that a tree trunk has branches.

But "master" is not trunk. It just a branch.

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

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
@ 2020-06-17 11:34 Alastair Houghton
  2020-06-17 11:49 ` Oleg
       [not found] ` <CAGqqT2w=ntxd6RNkpy175TbgiudUSOc0tAPoDsbjv=4V+73cXw@mail.gmail.com>
  0 siblings, 2 replies; 151+ messages in thread
From: Alastair Houghton @ 2020-06-17 11:34 UTC (permalink / raw)
  To: simon; +Cc: git

Just to stick my oar in here, *if* it’s going to change (and I’m yet to be convinced that it should, but I’m also not opposed in principle to a different name), **PLEASE** can we change it to “trunk”, which is what most of us were using before Git became popular anyway?  That at least makes sense in that a tree trunk has branches.

Kind regards,

Alastair.

--
http://alastairs-place.net


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16 12:54   ` Konstantin Ryabitsev
@ 2020-06-16 15:53     ` Sérgio Augusto Vianna
  0 siblings, 0 replies; 151+ messages in thread
From: Sérgio Augusto Vianna @ 2020-06-16 15:53 UTC (permalink / raw)
  To: konstantin; +Cc: ethanpet113, git, jrnieder, simon

Why do you keep pivoting this around the setting that allows to change 
the default? The whole issue is changing the default from master to 
something else. You are being intellectually dishonest.


^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16  0:23 ` Jonathan Nieder
@ 2020-06-16 12:54   ` Konstantin Ryabitsev
  2020-06-16 15:53     ` Sérgio Augusto Vianna
  0 siblings, 1 reply; 151+ messages in thread
From: Konstantin Ryabitsev @ 2020-06-16 12:54 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: Abram Wiebe, simon, git

On Mon, Jun 15, 2020 at 05:23:13PM -0700, Jonathan Nieder wrote:
> > We run into this kind of issue in software all the time, which is
> > why you see packages like PHP deprecate interfaces… but then still
> > need to keep them around for decades, simply out of fear of how much
> > would break if they actually took them out.
> 
> You might be comforted to find that the series at [1] allows
> requesting the previous behavior by running
> 
> 	git config --global core.mainBranch master
> 
> If that does not work in your setup, we want to know.  This same
> setting also allows tooling authors to experiment with the new default
> early.  Hopefully this can be useful.

In fact, distros and images can set this in /etc/gitconfig to set a 
distro-wide default.

-K

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
  2020-06-16  0:16 Abram Wiebe
@ 2020-06-16  0:23 ` Jonathan Nieder
  2020-06-16 12:54   ` Konstantin Ryabitsev
  0 siblings, 1 reply; 151+ messages in thread
From: Jonathan Nieder @ 2020-06-16  0:23 UTC (permalink / raw)
  To: Abram Wiebe; +Cc: simon, git

Hi Abram,

Abram Wiebe wrote:

> We run into this kind of issue in software all the time, which is
> why you see packages like PHP deprecate interfaces… but then still
> need to keep them around for decades, simply out of fear of how much
> would break if they actually took them out.

You might be comforted to find that the series at [1] allows
requesting the previous behavior by running

	git config --global core.mainBranch master

If that does not work in your setup, we want to know.  This same
setting also allows tooling authors to experiment with the new default
early.  Hopefully this can be useful.

Thanks and hope that helps,
Jonathan

[1] https://lore.kernel.org/git/pull.656.v2.git.1592225416.gitgitgadget@gmail.com/

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
@ 2020-06-16  0:16 Abram Wiebe
  2020-06-16  0:23 ` Jonathan Nieder
  0 siblings, 1 reply; 151+ messages in thread
From: Abram Wiebe @ 2020-06-16  0:16 UTC (permalink / raw)
  To: simon; +Cc: git

tl;dr It sounds like you mean well- but that has the potential to break a lot of things that expect the name master, so I’m not sure it’s a good plan.

I am against this as a default for technical reasons, and as an aside because as others have mentioned master is the in the context of a **Gold Master** meaning a product which is ready to ship. I’m sure your intent is well meaning but this does not appear to have the connotations you are ascribing to it.  Given that I am against it purely because I see it being confusing and a maintenance/backwards compatibility headache to change.

Someone said you can create whatever kind of _git init template_ you want and I think that is probably the best course of action who continue to take issue with what I think most consider pretty innocuous terminology.

----
Now for the technical problems that could arise from changing such a thing on a whim.

In software there is a concept of a known value which is expected to exist for min(lifetimeOfProduct,HEAD_DEATH_OF_UNIVERSE),
and no matter how much you want to get out from under it you always have unforeseen consequences.
It’s not quite as strong as a hardcoded constant, but it’s effectively a convention everyone follows kind of like a system’s environment variables.

In this case I can already see a few things that will go wrong:

1) Any utility that augments git and treats master as a special default branch (regardless of the note in the docs that there is nothing special about master except that it is created by default) is going to break or need to be reconfigured.

	1A)There are infrequently modified code bases with small teams that will have to unpick this,and may do so slowly 
	causing their package to be semi broken for some time

		1A.1)Any codebase which pulls dependencies form those repose will cascade into failure. goto (1A)

2)Any automation written by a user which expects the branch master to exist will break.
3)People who have already checked out the master ref may accidentally cause a divergent master history as habit causes them to merge into master rather than say main.
4)Any documentation of git either in official git documentation or in professional training materials will become considerably more confusing to new users as there are at present 15 years of archived documentation that refer to this branch as master.

We run into this kind of issue in software all the time, which is why you see packages like PHP deprecate interfaces… but then still need to keep them around for decades, simply out of fear of how much would break if they actually took them out.

Probably there will be more issues that we can’t predict without testing it (which again I am personally against doing unless it’s you’re own repo with your own template and your own rules).

It will probably be a maintainability nightmare that isn’t worth the fuss and I don’t even want to think of the aggregate lost man hours.

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re: Rename offensive terminology (master)
@ 2020-06-15 21:05 frederik
  0 siblings, 0 replies; 151+ messages in thread
From: frederik @ 2020-06-15 21:05 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

It sounds like the proposed changes are not going to be very
disruptive. However, legitimizing the inherent offensiveness of terms
like "master" and "slave" seems short-sighted to me. Any time that one
person has to work for another, a relationship exists which could be
abused, and the words describing this relationship would gradually
become "emotionally loaded". However, computers are full of instances
where one component is doing work for another component. Consider the
fact that the word "server" comes from "servus", meaning "slave" in
Latin. While "master" comes from "magis" meaning "greater". Are we
going to be able to eliminate the situations where one part of a
software system is greater than another part, or accepts commands from
it?

Furthermore, as someone already pointed out, who on this list speaks
for former slaves? I think someone who spoke for former slaves in my
country is the Honorable Elijah Muhammad. His books are full of
references to his teacher "Master Fard Muhammad" who came to American
in 1930 with a message of freedom, justice and equality for the Black
people of America. He taught his followers to pray to a God who is
"Master of the Day of Judgment", and to accept a 7th century prophet
who is "slave and messenger of God". For us to take offense at these
terms could signify greater racial awareness, or it could betray our
ignorance of the leadership of people, like Elijah Muhammad, who have
been trying to change the system for longer than we have.

If Git developers are interested in helping disadvantaged members of
our society, then I would suggest applying my patch from two years
ago, which de-alphabetized git(1), making it readable for novices.



On Sun, Jun 14, 2020 at 09:06:18PM +0000, Junio C Hamano wrote:
>Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
>
>> - 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
>
>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).
>

^ permalink raw reply	[flat|nested] 151+ messages in thread

* Re:    Rename offensive terminology (master)
@ 2020-06-14 15:09 Michael Felt (aixtools)
  0 siblings, 0 replies; 151+ messages in thread
From: Michael Felt (aixtools) @ 2020-06-14 15:09 UTC (permalink / raw)
  To: Don Goodman-Wilson
  Cc: Sérgio Augusto Vianna, philipoakley, Johannes Schindelin,
	git, Michal Suchánek, newren, brian m. carlson,
	Simon Pieters, stolee

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



Sent from my iPhone

> On 14 Jun 2020, at 15:58, Don Goodman-Wilson <don@goodman-wilson.com> wrote:
> 
> 
>> MASTER IS NOT INHERENTLY RELATED TO MASTER-SLAVE RELATIONS.
> 
> 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:
>> 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.


^ permalink raw reply	[flat|nested] 151+ messages in thread

end of thread, back to index

Thread overview: 151+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
2020-05-04 17:43 ` Robert P. J. Day
2020-05-04 23:10   ` N6Ghost
2020-05-04 17:45 ` Konstantin Ryabitsev
2020-05-04 18:31   ` Simon Pieters
2020-05-04 17:53 ` Robert P. J. Day
2020-05-04 18:18   ` Randall S. Becker
2020-05-05 23:16 ` brian m. carlson
2020-06-09 15:16   ` Simon Pieters
2020-06-09 16:02     ` Junio C Hamano
2020-06-09 16:28       ` demerphq
2020-06-09 18:10       ` Johannes Sixt
2020-06-09 19:02         ` Junio C Hamano
2020-06-09 20:52       ` Simon Pieters
2020-06-09 21:03         ` Junio C Hamano
2020-06-09 21:29           ` Simon Pieters
2020-06-10  9:51         ` Robert P. J. Day
2020-06-10 11:16           ` Kevin Swinton
2020-06-10 12:18           ` Don Goodman-Wilson
2020-06-10 16:30             ` Konstantin Ryabitsev
2020-06-14  0:03             ` Sérgio Augusto Vianna
2020-06-14  0:00         ` Sérgio Augusto Vianna
2020-06-14  0:45           ` Junio C Hamano
2020-06-14  0:50             ` Sérgio Augusto Vianna
2020-06-14  6:32               ` Don Goodman-Wilson
2020-06-14  6:34                 ` Don Goodman-Wilson
2020-06-14  8:47                   ` Sergey Lapin
2020-06-14  8:48                     ` Sergey Lapin
2020-06-14 12:07                   ` Sérgio Augusto Vianna
2020-06-16  7:31                 ` demerphq
2020-06-16  8:38                   ` Oleg
2020-06-16 19:33                     ` Elijah Newren
2020-06-17  1:17                       ` Sergey Lapin
2020-06-17  7:45                       ` Oleg
2020-06-16 10:04               ` Alex Smith
2020-06-16 11:29                 ` Konstantin Tokarev
2020-06-16 11:39                   ` Robert P. J. Day
2020-06-16 11:39                   ` Oleg
2020-06-17  7:27                   ` Sergey Organov
     [not found]                 ` <c0c2d9ad-1d67-8ebe-0063-524005ca97fe@whinis.com>
2020-06-16 11:38                   ` Whinis
2020-06-16 12:16                     ` Oleg
2020-06-16 13:30                     ` Konstantin Ryabitsev
2020-06-16 13:55                       ` John Turner
2020-06-16 14:14                         ` Michal Suchánek
2020-06-16 14:29                           ` Whinis
2020-06-16 16:19                           ` Alex Smith
2020-06-16 15:49                         ` Konstantin Ryabitsev
2020-06-16 16:09                           ` Whinis
2020-06-16 14:24                       ` Sérgio Augusto Vianna
2020-06-16 14:27                       ` Oleg
2020-06-16 16:03                         ` Konstantin Ryabitsev
2020-06-16 17:27                           ` Oleg
2020-06-16 17:42                             ` Konstantin Ryabitsev
2020-06-16 18:35                               ` Sergey Lapin
2020-06-16 19:03                               ` Oleg
2020-06-09 16:06     ` Konstantin Ryabitsev
2020-06-09 19:01       ` Don Goodman-Wilson
2020-06-14  0:05         ` Sérgio Augusto Vianna
2020-06-14 19:08           ` brian m. carlson
2020-06-14  8:49             ` Johannes Schindelin
2020-06-14 19:17             ` Sérgio Augusto Vianna
2020-06-15  2:16             ` Taylor Blau
2020-06-15  2:54               ` Sérgio Augusto Vianna
2020-06-09 22:36     ` brian m. carlson
2020-06-16  8:50     ` Michal Suchánek
2020-06-10 21:30   ` Johannes Schindelin
2020-06-10 22:35     ` Edward Thomson
2020-06-10 22:51     ` brian m. carlson
2020-06-11 11:52     ` Michal Suchánek
2020-06-11 11:59       ` Don Goodman-Wilson
2020-06-11 12:52         ` Derrick Stolee
2020-06-11 15:14           ` Junio C Hamano
2020-06-14  2:59             ` Johannes Schindelin
2020-06-15 10:07               ` Michal Suchánek
2020-06-12 13:21           ` Philip Oakley
2020-06-14  0:41             ` Elijah Newren
2020-06-14 10:54               ` Philip Oakley
2020-06-14 12:20                 ` Sérgio Augusto Vianna
2020-06-14 13:58                   ` Don Goodman-Wilson
2020-06-14 14:05                     ` Sérgio Augusto Vianna
2020-06-15  3:52                     ` Andrew Ardill
2020-06-15  4:45                       ` J. Paul Reed
2020-06-15  5:19                         ` Andrew Ardill
2020-06-17  8:27                     ` Michal Suchánek
2020-06-14 18:19                   ` Konstantin Ryabitsev
2020-06-14 18:23                     ` Sérgio Augusto Vianna
2020-06-14 19:04                       ` Konstantin Ryabitsev
2020-06-14 19:08                         ` Sérgio Augusto Vianna
2020-06-14 19:16                           ` Konstantin Ryabitsev
2020-06-14 20:41                       ` Philip Oakley
2020-06-16  7:36                       ` demerphq
2020-06-16  7:43                         ` Michal Suchánek
2020-06-16  8:01                           ` demerphq
2020-06-16  8:59                             ` Michal Suchánek
2020-06-17 19:56                             ` Junio C Hamano
2020-06-17 20:10                               ` Jonathan Nieder
2020-06-17 20:17                                 ` Jonathan Nieder
2020-06-18  7:57                                   ` demerphq
2020-06-18  8:38                                     ` Oleg
2020-06-18 10:17                                       ` demerphq
2020-06-18 15:23                                     ` Konstantin Ryabitsev
2020-06-18  7:40                               ` demerphq
2020-06-18 18:04                                 ` Junio C Hamano
2020-06-14 21:06                     ` Junio C Hamano
2020-06-14 21:15                       ` Eric Wong
2020-06-14 21:39                         ` Junio C Hamano
2020-06-15 18:07                   ` Jonathan Nieder
2020-06-15 18:18                     ` Sérgio Augusto Vianna
     [not found]                       ` <CAAwdEzDgJuoQJAZsrT0piuZPVP6nJTSB9RCbcuXO03-BYTnmOQ@mail.gmail.com>
2020-06-15 19:37                         ` Sérgio Augusto Vianna
2020-06-15 19:50                           ` Alexandru Pătrănescu
2020-06-15 20:44                             ` Elijah Newren
2020-06-15 20:42                           ` Randall S. Becker
2020-06-15  0:34     ` James Ramsay
2020-06-15 21:38     ` Elijah Newren
2020-06-15 21:46       ` Elijah Newren
2020-06-16 21:07     ` ZeeVriend
2020-06-17  7:49       ` Oleg
2020-06-17 20:48         ` ZeeVriend
2020-06-18  8:28           ` Oleg
2020-06-17 20:52         ` ZeeVriend
2020-06-13 23:56   ` Sérgio Augusto Vianna
2020-06-13 23:53 ` Sérgio Augusto Vianna
2020-06-14 14:59 ` Thomas Adam
2020-06-14  8:04   ` Johannes Schindelin
2020-06-14 15:13   ` Michael Felt (aixtools)
2020-06-14  8:27     ` Johannes Schindelin
2020-06-14 15:51     ` George Of The Jungle
2020-06-14 15:20 ` Sérgio Augusto Vianna
2020-06-15  0:02 ` Sérgio Augusto Vianna
2020-06-15 14:39 ` Sérgio Augusto Vianna
2020-06-15 14:39 ` Sérgio Augusto Vianna
2020-06-15 23:15 ` Sérgio Augusto Vianna
2020-06-16  1:00 ` Fang-Pen Lin
2020-06-16  1:38 ` Sérgio Augusto Vianna
2020-06-21 19:50 ` Social Justice Movements [was: Rename offensive terminology (master)] Luke Kenneth Casson Leighton
2020-06-23 23:21 ` Rename offensive terminology (master) Gunnar Liljas
2020-06-24  1:16   ` Whinis
2020-06-24  8:19   ` lego_12239
2020-06-26 10:08     ` Gunnar Liljas
2020-06-26 10:34       ` Oleg
2020-06-14 15:09 Michael Felt (aixtools)
2020-06-15 21:05 frederik
2020-06-16  0:16 Abram Wiebe
2020-06-16  0:23 ` Jonathan Nieder
2020-06-16 12:54   ` Konstantin Ryabitsev
2020-06-16 15:53     ` Sérgio Augusto Vianna
2020-06-17 11:34 Alastair Houghton
2020-06-17 11:49 ` Oleg
     [not found] ` <CAGqqT2w=ntxd6RNkpy175TbgiudUSOc0tAPoDsbjv=4V+73cXw@mail.gmail.com>
     [not found]   ` <CAGqqT2zFkCUTdUnzdp4oTR2cnxBpKeY-EZtxacLLVDsF8Jiekw@mail.gmail.com>
2020-06-17 12:27     ` Zac McChesney
     [not found] <'CAOAHyQyn_ow7_nCJ+Jorr76_=1=_kuBAD1KhqReqVfRQQbmgiw@mail.gmail.com'>
2020-06-26 18:37 ` Neil Stoddard
2020-06-29  8:59   ` Michal Suchánek

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git