GioCities

blogs by Gio

Is (git) master a dirty word?

Git is changing. GitHub, GitLab, and the core git team have a made a system of changes to phase out the use of the word “master” in the development tool, after a few years of heated (heated) discussion. Proponents of the change argue “slavery is bad”, while opponents inevitably end up complaining about the question itself being “overly political”. Mostly. And, with the tendency of people in the computer science demographic to… let’s call it “conservatism”, this is an issue that gets very heated, very quickly. I have… thoughts on this, in both directions.

Formal concerns about problematic terminology in computing (master, slave, blacklist) go back as early as 2003, at the latest; this is not a new conversation. The push for this in git specifically started circa 2020. There was a long thread on the git mailing list that went back and forth for several months with no clear resolution. It cited Python’s choice to move away from master/slave terminology, which was formally decided on as a principle in 2018. In June of 2020, the Software Freedom Conservancy issued an open letter decrying the term “master” as “offensive to some people.” In July 2020 github began constructing guidance to change the default branch name and in 2021 GitLab announced it would do the same.

First, what role did master/slave terminology have in git, anyway? Also, real quick, what’s git? Put very simply, git is change tracking software. Repositories are folders of stuff, and branches are versions of those folders. If you want to make a change, you copy the file, modify it, and slot it back in. Git helps you do that and also does some witchery to allow multiple people to make changes at the same time without breaking things, but that’s not super relevant here.

That master version that changes are based is called the master branch, and is just a branch named master. Changes are made on new branches (that start as copies of the master branch) which can be named anything. When the change is final, it’s merged back into the master branch. Branches are often deleted after they’re merged.

It looks something like this, with each branch on its own horizontal line:

git branching example

Unlike some other programming paradigms, git never used the word “slave”, only “master”. Branches are simply referred to as branches, not “slave branches”. The only thing particularly special about the master branch is its use as this master copy. When you start a git project the default branch is named master, but that’s all the special treatment it gets.

So why are people upset about the use of the word “master”? Or, alternatively, why isn’t everyone upset by the use of the word “master”, and how did it ever fall into use in the first place?

The problem here is tied up in the very concept of subordination. There are a few relevant definitions of the word “master” here: “chief, principal, or predominant”, “controlling all other parts of a mechanism”, and “a film used for making duplicate prints”. All of these definitions apply to the master branch in coalescence. The master branch is the dominant branch in the process, the first branch in an ordered list, the authoritative version. Behind all those definitions though is the common, fundamental meaning of the word; “master” means something with power over something else, which demands we look at the concept of subordination.

The word subordinate (sub-order) means to be of a lower order, or lower class. This invokes some of the same ideas as incommensurability, where orders are not a matter of scale, but of category. Something in a subordinate rank is categorically inferior to all things in a superior (super -ior) rank. (see also “principal”.)

This is an abhorrent concept to apply to humans, along any line. There should never be a category considered subordinate, whether delineated by race, or gender, or intelligence, or birthplace. Humans can be in a subordinate role (all cashiers are of a lower rank than their managers in the context of their job, for instance), but must not be subordinate per se. While slavery is of course the ultimate example of this, the problem of putting things (people, machines, systems) in control of humans is a persistent one, and a recurring evil in any area of life.

But is subordination, as a concept, bad, in the context of a society that historically misuses it on humans? No. I mean, it mustn’t be. You have to have orders and classes and groups in the fields of mathematics, or you can’t even sort things. Rank, as a concept, is as close to a value-neutral thing as you can get. But that quick “neutral concepts can’t be wrong” doesn’t address the real issue.

People aren’t upset at the idea of subordinate branches. The strictly hierarchical way work is done (with one master version) isn’t up for dispute here, just the names used. But also, no one is saying the word master doesn’t accurately describe that subordination-based workflow. Unlike some other cases in computer science, the “master” label isn’t even primarily a metaphor for human slavery.1 It isn’t over-generic, and replacing it doesn’t help increase clarity.

So what is the actual concern? The original Software Freedom Conservancy cites the term as being “offensive to some people and we empathize with those hurt by the use of that term.” GitHub skips over the question entirely and just says “Many communities … are considering renaming the default branch name of their repository from master.” The python issue (which was approved) just says “For diversity reasons, it would be nice to try to avoid “master” and “slave” terminology which can be associated to slavery.” and simply cites other similar discussion threads.

The problem is the word itself, and the very strong associations some people have with it. People aren’t upset about the concept of subordination when applied to revision history, they’re upset about the very real atrocity of human subordination, which subordination in general happens to remind them of.

It doesn’t go much further than that, but it might not need to: language is associations, after all. Use of the word “master” in the context of computer science is associated with use of the “master/slave” model (again, used commonly in the context of computer science) which obviously has a very tight association with the real-life atrocities of human-to-human master/slave slavery. I titled this article “Is (git) master a dirty word”. That’s not a rhetorical question I’m pretending you asked so I can give you my easy answer, that’s the real question at stake here. Has the word been dirtied? Is that even a thing that can happen? Like with far too many questions, this seems to fall all the way down to linguistics.

So, if it’s only the word association… is that enough to warrant major changes?

There is a lot of fourmlike chatter about this topic online, but I think my two favourite artifacts to probe are NISTIR 8366 and draft-knodel-terminology.

NISTIR 8366 is the National Institute of Standards and Technology’s Interagency Report titled “Guidance for NIST Staff on Using Inclusive Language in Documentary Standards”, and functions as a standardized guidebook for choosing appropriate language within CS. It’s a short document — only 8 pages of content — that covers a wide range of topics. Section 4.1 is a bullet-point list with headers like “Avoid terms that assign a gender or sex to inanimate objects” and “Avoid colloquialisms, metaphors, similes, idioms, and other unnecessary jargon”. This is the section where the document first brings up “master/slave”, under the header “Avoid terms that perpetuate negative stereotypes or unequal power relationships”. The same document later gives the example “The terms “master/slave” to describe a model where one device or process controls another as subordinate should be avoided.”

I find this to be an interesting topic to interrogate. This says that even under the premise of describing a subordinate relationship, the “master/slave” metaphor should be avoided. Do terms that describe unequal power relationships really perpetuate them? What if — as in computer science — unequal power relationships can actually be the desired and correct outcome?

draft-knodel-terminology, meanwhile, is “Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs”, a draft for the IETF (a major internet standards body) written by Mallory Knodel. It’s specifically about the use of inclusive language within RFCs (Requests For Comment, internal memos) and makes a strong case based on the importance of effective communication. It dedicates a full page to the master/slave metaphor specifically:

Master-slave is an offensive and exclusionary metaphor that will and should never become fully detached from history. Aside from being unprofessional and exclusionary it stifled the participation of students […]

…

Ultimately master-slave is a poor choice since it is 1) being used less frequently already 2) in a variety of applications 3) to correct perceived exclusionary effects 4) at the request of concerned members of the technical community.

It then proposes a few general-purpose alternatives, including “primary/secondary” (based on authority) and “primary/replica” (based on originality). Unfortunately, neither of those map well to branches; calling a branch “secondary” is confusing terminology, as there can be many simultaneous peer branches, and, as branches’ entire purpose is to be changed, “replica” doesn’t fit well either.

Another on the side of making the change, Chrome developer Una Kravets wrote:

Github Replacing “Master” With “Main” is a Huge Win for Inclusion in Tech is a great article about this that points out how making minorities less comfortable (however marginally) directly harms the industry by keeping people out:

…recruiters and those complaining about the (alleged) ever-elusive “pipeline problem” of getting minorities into tech have no idea how much of a road block unnecessarily non-inclusive terms like “master” and “slave” have in causing many minorities who do enter the “pipeline” to leave at higher rates than their white counterparts.

However (and this is the reason this article is “great”, unfortunately) right beneath this excellent point is a section titled ““Master” Almost Caused Me to Quit Software Engineering” in which the author demonstrates a failure to understand git’s conceptual model:

Imagine every time you save a file, instead of clicking “save as” or “open” for a file you have to explicitly type “master can I save this” and “master please open this.” That’s how Github works — that’s what Software Engineers do!

For those of you who are technical, you know that sometimes “master” will give you want you want, but other times you essentially have to beg “master” for the updated version of your files.

Why is this called “master” anyway? What am I even doing here at 3am dealing with “master” like this is the 1800s?

This is very emotionally rich language, and I understand how feeling this way would be incredibly discouraging. Factually, though, it’s completely wrong. master is a document, not an administrator; developers don’t ask it for things, it doesn’t grant you things, it isn’t an actor of any kind. There are some compsci “master/slave” models that are like this, but git isn’t one of them. The notion of the developer/software interaction here is incorrect. What’s being described here is a frustrating learning curve exacerbated by the language the software used. Exacerbated to such an extent that, at the time this article was written, the author seems to have given up on understanding entirely, which isn’t an outcome anyone wants.

I think this is one of the legitimate things that frustrate the master holdouts. It often seems like the proponents of making these changes are much more focused on the emotional impact of the language than they are on the conceptual model of the thing they want to change. With a case like the one above, the question becomes “If he understood the model, would he even have the complaint? And does his distress prevent him from understanding the model?” If the people pushing for the change aren’t focused on the mechanics, the people who only care about the mechanics see the argument as flimsy. And when the individual arguments for a cause seem flimsy, the cause as a whole feels flimsy.

As seen on the python thread, the objections to master can seem like “vaguely formed notions” rather than pressing issues:

Raymond Hettinger wrote: Mostly, I don’t think these changes should be made, particularly in cases where “slave” isn’t mentioned at all. The word “master” is used in many contexts where master/slave doesn’t apply (such as “master key”).

…

If a particular passage is demonstrably unclear or offensive, it should be changed; otherwise, we shouldn’t let vaguely formed notions of political correctness shape other clear uses of plain English.

As far as I can’t tell there isn’t a single instance where the docs use “master” as a reference to human slavery or where the use could be seen to imply an endorsement of that notion.

This is a fairly typical argument. “If there’s a specific issue with a specific section, it needs to be changed. If there’s an inappropriate reference to actual human slavery, that could be in such poor taste that a change is demanded, but there isn’t.”

I think part of what people are complaining about when they say this movement seems “political” is their belief that the intent behind the change should not be a significant part of what makes the change itself good, that it’s insufficient for the notion to be the driving factor. For the long-term structural changes being proposed to be valid, the changes need to be able to stand on their own, not completely dependent on their specific cultural context.

Here’s my devil’s advocate thought experiment on this: if the faction proposing these same changes had the opposite background, would that make them horrifying? Imagine a cause led by historical revisionists looking to whitewash the atrocities of human slavery, purging references to the concept in an attempt to prevent people from being reminded of their history. And, in an attempt to do this, proposed exactly the same language change. Would that be a monstrous thing to do? Would that make the change itself a monstrous thing to implement? If the “nobility” of making the change is the kind of thing that can be impacted by the mere intentions of the proposers, is it the kind of change that should be made to core infrastructure?

There are other… less sophisticated arguments out there for keeping master, though. For instance, let’s look at some of what one of these people from the mailing lists has to say:

Felipe Contreras wrote: It’s not a coincidence that nobody found the term problematic for 15 years, and suddenly in the height of wokeness–2020 (the year of George Floyd, BLM/ANTIFA uprising, and so on)–

oh god, let’s stop looking at that now. I mean, I guess it’s not a total surprise that’s how mr. anti-woke, eminent discusser breaks the ice, the git. There are actually some half-decent points buried the heck in there, but urgh is it painful to read.

The problem is people like this approach the issue from a defensive, dire mindset that doesn’t allow for any good faith or empathy with the “other side”. Sure, there will always be some people who take up causes in bad faith, sure, but to demand that everyone is faking their distress is dishonest, and lazy. More importantly, the combative stance is not one that allows for these issues to be resolved peacefully. It fractures a community of people who are ostensibly working towards a common goal into factions at each others’ throats over perceived attacks that are often simply miscommunication.

In this enormously charged issue, filled with people throwing around words like “diversity” or “sjw” or “political correctness”, the actual positions seem to come down to “Changes should only be made if demonstrably, mechanically necessary” and “Changes that make a group of people more comfortable should be made.” Master isn’t some magic word that git needs to use; that isn’t the complaint. The concern is about the necessity of the change, and that the change replaces a more accurate metaphor with a less accurate one.

Which is right? I don’t know. Even after all that, I find myself tending towards the former. I look at the latter from a project management perspective (where frivolous change requests must be guarded against with ferocity) and think “that way lies madness.” As a language guy, too, I feel like “master” describes the actual relationship of subordination that’s being described much better than the replacement (“main”). It almost feels like a lesson in whitewashing uncomfortable words away while keeping the structures they describe. In this case, though, the structure is fine; it’s just the word that isn’t — democratically, for better or worse.

I realize I’m teetering on the edge here of out-and-out saying “if you are made uncomfortable by this, you are wrong”, which is certainly something I did not set out to do, and something I categorically dislike saying. But right now, it seems to me like that might actually be the case here.

More inclusive language in computer science is definitely a good thing, and we absolutely don’t need to be using slave language to describe things like producer/consumer relationships. (Honestly, an awful lot of things got named master/slave for what seems less like metaphor than laziness. A lot of replacements have been in cases where the master/slave metaphor was technically inaccurate or misleading.)

I picked git to focus on here because it’s one of the cases where there’s the least clear need for change, and therefore both the most room for debate and the most interesting conversation to be had. We need to be using the right language for the job, and we need to be mindful of the effects words have on other people — something the computer science community is particularly bad at. But in cases where the underlying relationship really is one thing being in subordination to another, maybe it’s good to be in the habit of describing them accurately and honestly.

Comments