Hi all, On Tue, 5 May 2020, brian m. carlson wrote: > On 2020-05-04 at 17:20:33, Simon Pieters wrote: > > "master" is an offensive term, as it can be interpreted as being > > slavery-origin terminology. See > > https://en.wikipedia.org/wiki/Master/slave_(technology)#Terminology_concerns > > > > The Python programming language, and various other projects, have > > taken a stance and moved away from offensive terminology including > > "master". See https://bugs.python.org/issue34605 > > > > When different projects using git decide to move away from "master" as > > the name of their main branch, inconsistency ensues between projects. > > See https://github.com/desktop/desktop/issues/6478 (and "Related > > Issues and Projects"). > > > > To avoid offensive terminology and to avoid further inconsistency, I > > think git should use a different branch name than "master" when > > initiating a repo. I don't have a strong opinion, but I like "main" > > since it shares the first two characters and it's shorter. > > I've been busy and haven't had much time to respond to this, but I've > gotten some feedback from other people on this issue and so I'll share a > few thoughts. > > Others have pointed out that "master" meaning a canonical source may not > share the problematic origins mentioned above. From feedback I've > received, I get the impression that "master", even though from a > different origin, brings the idea of human bondage and suffering to mind > for a non-trivial number of people, which of course was not the > intention and is undesirable. I suspect if we were making the decision > today, we'd pick another name, since that's not what we want people to > think of when they use Git. Indeed. I have to admit that I did not understand the breadth of how problematic such a term is. I am a Caucasian male, and in the society in which I grew up, that comes with a lot of privilege that I am only beginning to understand in its entirety. One of the consequences was that I was unaware, even oblivious, to the emotional response certain terms can elicit. Just because those terms do not affect me very much, personally, does not imply that I don't care. So I will try to do my share in helping with this topic. It might not be much, in the bigger picture, yet together with other, equally small steps, we might be able to do some good. A growing number of projects does indeed rename their default branches, and I want to do the same with Git for Windows' repositories. I have reached out to Billy Griffin (the PM of GitHub Desktop) to learn what might be good candidates for the default branch name, as GitHub Desktop changed their repository's main branch name recently. This is what he told me: [W]e did some research looking at the data at GitHub of the most commonly used default branch names other than `master`. Most of them were things like develop, release, staging, stable, production, etc. that denoted some stage of the software lifecycle. We thought that none of these are good options because a universally applicable default name should allow for teams and projects to work in different ways (and obviously if teams want to change it to reflect their workflows, they're free to do so just like they do today - we use `development` as the default branch in desktop/desktop, for example). The three most common names that *weren't* in that category were main, trunk, and source. "Trunk" has roots in SVN so there's some precedent for it, but we've heard feedback that it's not particularly intuitive for non-native English speakers, and "source" in my opinion isn't accurate because it's only a single branch, not the entire source. We've also seen "default" floated and it exists in mercurial, but we've also heard feedback that it's potentially sensitive due to financial default, so we might as well choose something else if there's another good option. For that reason, we're thinking that `main` would likely be a good choice because the name corresponds nicely to its purpose as the default branch of a repo. It's also conveniently short to type, and tab complete would continue to *just work* for those concerned about muscle memory because the first two letters are the same as `master`. So I plan on using `main` for the repositories in the https://github.com/git-for-windows org. Billy then shared this information with James Ramsay of GitLab to discuss how GitHub and GitLab can coordinate on changing the default branch name in new repositories. Here is the GitLab ticket to track their progress: https://gitlab.com/gitlab-org/gitlab/-/issues/220906 > Clearly we have compatibility concerns to consider though, so if we > decided to make a change, we'd probably want to make it in a 3.0, which > as far as I'm aware hasn't been discussed yet. I also wondered what > such a change would involve, so I did some research. > > It appears that if we made the obvious one-line change to > builtin/init-db.c, we'd have 304 tests that fail, which is about a third > of our test suite. I haven't examined any of these tests, so I don't > know what would be involved in changing them. I imagine a project to do > so would involve setting an environment variable in the test setup code > (e.g., MAIN_BRANCH) and replacing instances of "master" with that until > everything works with an alternate value of that variable. Picking the > new name itself could be deferred until later, and we could choose from > some popular alternatives. As mentioned elsewhere in this thread, Don (Cc:ed) and I started working on this, and I just submitted it: https://lore.kernel.org/git/pull.656.git.1591823971.gitgitgadget@xxxxxxxxx/ That patch series adds a config variable allowing to override the default name of the default branch. I hope to see this finalized and sent off to the Git mailing list relatively soon: being strictly opt-in, it should be really uncontroversial and obviously helpful. > There's also the documentation, which at first glance seems mostly to be > examples, many of which could be changed to any suitable branch name. > There are a large number of those cases and someone would have to audit > them all. Indeed. The good news is that this audit can be split between multiple volunteers. > So it looks like this would be a reasonable amount of work for someone > if they decided to pick it up as a project. Since I have limited free > time and am working on the SHA-256 transition, I won't be doing this, > but if someone did pick it up, I would be happy to do some reviews, > provide feedback, and include a few patches while doing other work in > the area. Based on the above-mentioned patch series, I have an end-to-end proof-of-concept (with one or two monster patches that still need to be split up) to change the default branch name to `main`. It is complete in the sense that it passes the test suite (also in SHA-256 mode when merging the `bk/transition-stage-4` branch), but it has a couple of too-large commits that still need to be split up: https://github.com/gitgitgadget/git/pull/655 I agree with brian that it was _quite_ a decent amount of work, and that it will still require a decent amount of work going forward. My current plan is to split this up into several patch series: - above-mentioned patch series was already split out, and submitted for review, introducing `core.defaultBranchName` (and `GIT_TEST_DEFAULT_BRANCH_NAME`). From my point of view, this would be safe to have even as early as in Git v2.28.0. - a patch series that tackles the hard parts of the test suite: one by one, the test scripts will be patched to include GIT_TEST_DEFAULT_BRANCH_NAME=main export GIT_TEST_DEFAULT_BRANCH_NAME at the beginning, and they will be patched to pass. This patch series should only be accepted once there is consensus (see below for more on that). - a patch series to tackle the easy parts of the test suite, i.e. the scripts that needed only automated patching (`sed` magic). This patch series should only be accepted once (if!) the previous one was accepted. - a patch that moves the GIT_TEST_DEFAULT_BRANCH_NAME assignment to `t/test-lib.sh` to ensure that the entire test suite passes with the designated new default branch name. This patch really only makes sense once consensus is reached not only that we want to change the default branch name, but also to what name it should be changed. The main intention of this patch is to ensure that the test suite keeps working with the new default branch name during the (probably quite long) time when Git holds off from "flipping the switch", i.e. until the above-proposed Git v3.0. - a patch series that changes the default, and then addresses all of the documentation and the error messages mentioning the default branch name. This would conclude that effort. Or maybe there are a couple more natural seams at which to partition those patches better, to improve reviewability (and to reduce reviewer fatigue). > I realize there isn't agreement on a direction forward or whether this > is worth doing at all, but since Git usually operates by providing > feedback on an initial set of patches, I thought I'd sketch out what > that might look like for folks who were interested. Thank you for doing this. As you hint, there are the technical challenges, but also the cultural challenges. I think I outlined a sensible path forward to address the technical challenges above, and now I would like to talk about a path forward to address the social/cultural ones. I do realize, of course, that as a white person identifying as male, there is a real big risk that my efforts look as if I want to force everybody to accept a new default branch name, to adjust their tools and scripts, their workflows, for maybe not a big enough gain to be worth all that work. So let me make my intentions clear: I do care about inclusive language, and even more so about inclusive culture, and I would like Git to be changed accordingly. And as I learned from personal conversations with friends and colleagues, as well as from stories and books, Git's current default branch name is eliciting emotional distress. Encouraged by Emily in #git-devel (who pointed out that a subject like this is much better discussed seeing each others faces and hearing each others voices), I would like to organize another Virtual Contributor Summit, this time focused on inclusive language in Git, what we can do about it, and what we should do about it (or not). Tentatively, I would like to propose having this meeting in the coming week, via Zoom, just like we did the Virtual Contributor Summit last September. Could I ask all interested parties to reply to this email? > I should point out that it's also possible for users who dislike the > current name to use a template to change the default branch name like > so (using the proposed "main"): > > mkdir -p ~/Templates/git > cp -a /usr/share/git-core/templates/* ~/Templates/git > echo 'ref: refs/heads/main' > ~/Templates/git/HEAD > git config --global init.templateDir ~/Templates/git > > Then "git init" will set your default branch to "main" instead of > "master". This does have the weirdness that it claims it's > reinitializing your repository, but otherwise appears to work. That is > of course orthogonal to changing Git itself, but is an option for folks > who'd like to make a change now. That's a pretty good workaround in the meantime. I would like to point out that there are two slight issues with this workaround, in addition to the "re-initializing" message: - copies of Git's templates can become stale during upgrades, as newer versions of Git might come with modified template files. - Git's template files are sometimes used to install a set of hooks that was aggregated by the administrator(s). This workaround would interfere with that, at least if the set of pre-configured hooks gets modified. For those reasons, I hope that the `core.defaultBranchName` patch will be on its way into git/git soon. Thank you, Johannes > -- > brian m. carlson: Houston, Texas, US > OpenPGP: https://keybase.io/bk2204 >
