Re: Rename offensive terminology (master)

[Andrew Ardill <andrew.ardill@gmail.com>]

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