I was wrong

I've been using Git for years and always took for granted that the default branch name was master. After all, it's been that way since May 2005 long before I started using Git. At the same time, I've been very supportive of efforts to eliminate master/slave metaphors in tech. I hated using those terms for databases or tools I used in my day-to-day work, but I gave Git a pass.

I was privileged enough to hold this seemingly incongruent dichotomy in my head as "okay." When pressed and asked, I was happy to accept that Git didn't have slave branches. Thus, the use of the term master must reference a "master copy", like similar terms in art and audio engineering of a master or mastering. I know that I've offered this explanation to folks before, while still being happy to use master myself and let other people choose a different default branch if they wanted to.

Whenever it came up in the Git community at large, this was the accepted answer (as far as I know). And in general, many tools - GitHub and GitLab, for example - allowed users to change their default branch. It seemed that it was settled. But still, the question always itched at my brain: Is it inclusive to use a term like master even if it's not attached to slavery?

Well,even if you think the answer to master question is yes, here's the problem: We're wrong about the intended meaning of master in a Git context. My colleague James Ramsey who may know more about Git than any human on the planet found this thread, which explains it is just as likely that master is referencing Bitkeeper's master/slave mechanism. Bitkeeper uses master/slave termonology when referencing repositories.

Since Git was built as an open-source alternative to Bitkeeper, I think it is safe to say that the origin of git master is rooted in master/slave terminology. Any attempts to now say master refers to a master recording, or a master craftsman is a false etymology.

It's now clear to me that we have to move off of master as the term for the default branch in Git. There is a lot of effort around this downstream of git itself (e.g. setting defaults in GitLab, changing git-for-windows), but I'm happy to see and support the fact that the upstream Git maintainers are also going to seriously consider changing master to something else in Git 3.0. Also, sooner than a major release, the Git maintainers could choose to add in the ability for git init to prompt the user for a default branch.

We need to make this change, and I was wrong to not push for it sooner. I need to do better. I need to make sure that ally is a verb and not a noun in my life.

If you are neutral in situations of injustice, you have chosen the side of the oppressor. ― Desmond Tutu

Visit blacklivesmatter.carrd.co to find out what you can do to make ally a verb for yourself.

Update 2020-06-15

Additional evidence that the original reference was to master/slave terminology was found from a 2005 post from the creator of Git:

What does that mean? It means that in a mirroring schenario, you can, for each git tree, do:

(a) On the slave: cat .git/refs// | sort | uniq > slave-ref-list

(b) On the master: cat .git/refs// | sort | uniq > master-ref-list

(c) On the master:

Update 2020-06-018

You can also find out how to change your own default branch name in GitLab and everywhere else in other blogs I've written. It's a tiny step, but it is one you can control. There is so much more we can do - as I mentioned above in the original post, visit blacklivesmatter.carrd.co for other more critical actions you can take to help.