Re: Rename offensive terminology (master)

Hi all,

On Tue, 5 May 2020, brian m. carlson wrote:

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

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@gmail.com/ 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.

Indeed.

The good news is that this audit can be split between multiple volunteers.

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

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?

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