Re: Rename offensive terminology (master)

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 [off-list ref] writes:

quoted

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