Re: Rename offensive terminology (master)

From: frederik@ofb.net <frederik@ofb.net>
Date: Jun 15, 2020, 21:05 UTC
Message-ID: <20200615210501.GA526224@localhost>

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:

Show 56 quoted lines

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