Rename default branch from "master" to "main"

[trivikr]

Is your feature request related to a problem? Please describe. Lot of software developers are discussing on twitter to rename default branches for their projects from "master" to "main" or equivalent https://twitter.com/search?q=master%20branch&src=typed_query

The primary reason being master-slave an oppressive metaphor.

Describe the solution you'd like Node.js core follows the trend to change the industry standard, and renames default branch from "master" to "main" or similar

Describe alternatives you've considered Sticking with existing master branch name for the default

EDIT: Updated "renaming master to main" to "renaming default branch name from 'master' to 'main'"

[devsnek]

This is not a technically difficult task (https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx) but it might break some things. I definitely think we should try to change it.

[ronag]

Does this mean we would have to change the cluster API (which includes master in its vocabulary) as well in a semver-major?

[Gallardo994]

This is getting silly already. No way it makes any sense.

UPD: How is this offtopic? Please stop bringing politics into development world. That's just mindblowingly silly.

[ghost]

That is hilarious. From defacing nodejs.org with blm propaganda, to renaming master branch to avoid similarity with master-slave metaphor. What is the next requirement OpenJS will ask for? To remove the test directory to avoid similarity with testicles? Please keep technical aspects of the software free of politics and globalistic propaganda.

[devsnek]

@ronag i don't think that cluster was brought up in this thread, though it has been discussed on other occasions.

[ronag]

I'm -0 to the change itself. I don't think that changing it because it is "industry standard" is a valid argument, at least not yet. If we are changing it because we think it is a loaded/inappropriate word, then I think we should remove all occurrences to remain consistent with that decision.

[benjamingr]

I don't feel like this is something people have actually complained about. When we've made these changes in the past (for example in child_worker.suicide) it was guided by someone acting in good faith feeling strongly about the terminology.

If someone from the project's base does feel strongly about it - I suggest we rename it, though master is the default git branch name so I would caution we pick our battles.

I vote we:

• Don't change the name from master to something else currently.
• Change it when a contributor/collaborator feels strongly enough about this.

Of course, if you @trivikr personally feel strongly about this then I support you :]

[trivikr]

Of course, if you @trivikr personally feel strongly about this then I support you :]

I don't feel strongly against using master branch name. I proposed it as I plan to follow it in my personal projects and work projects, and wanted to ask Node.js community.

Should we add this to tsc-agenda?

though master is the default git branch name so I would caution we pick our battles.

Is there an equivalent ask in git repo? If not, we should create one.

[benjamingr]

Also, to all the people making the drive by comments: please keep discussion civil and remember Node.js has a code of conduct. If you can't be polite here you really don't have to comment. It's fine to either support or object to the proposed change (or any proposed change) as long as you are civil - we do not tolerate abuse towards the project and its members here.

To collaborators: kind reminder that you are allowed to ban users that make these sort of comments and to hide said comments - but please update the project (as explained there) with what actions you took so that any moderation actions taken are done in full transparency.

[benjamingr]

Is there an equivalent ask in git repo?

I'm not sure where the git repo is - but I recommend trying the mailing list and asking there https://git-scm.com/community

I think "doing whatever git does and bringing the issue to their attention" is a viable strategy - but again, I don't feel particularly strongly about the use of "master" and if someone else does - sure.

Should we add this to tsc-agenda?

I'm not entirely sure why?

[trivikr]

Should we add this to tsc-agenda?

I'm not entirely sure why?

To let tsc make a call on this request.

Other option would be to keep this issue open for a week or so, and see if it gathers more feedback or support.

[benjamingr]

To let tsc make a call on this request.

As far as I understand it that's not how our governance works. Any collaborator may add the tsc-agenda label for an issue so it gets TSC eyes on it - but that should only be done if consensus seeking fails. It's an escape hatch for when we need to force a vote which is pretty rare. At least that is my understanding of the process.

So far everyone here seems to be pretty in sync (no one is opposed but no one is particularly in favor). We're not even in disagreement 😅

[trivikr]

I'm not sure where the git repo is - but I recommend trying the mailing list and asking there git-scm.com/community

I've sent an email to Git Community mailing list, and will update here once they come up with a decision.

[ljharb]

Bear in mind that URLs linking to master will not redirect to the new default branch name (and for repos where it matters, which isn't this one, github-pages only works on the default branch when it's named master). It may be worth waiting for Github to fix these discrepancies before making the switch.

(to be clear; i'm in favor of making the change, and "main" seems as good as anything else, but the disruption caused by Github's incomplete support for a non-master default branch are significant)

[jasnell]

+1 to main but I do want to see what lead GitHub takes in making this easier

[MylesBorins]

I personally feel very strongly that we should change this.

+1 to main

[AshCripps]

I would be -1 untill a plan is drawn for the changes. This could cause a lot of issues with our build ci which would need to be accounted for.

[benjamingr]

Ok, it looks like there are people in favor in the org who feel strongly that we should change this. So far no objections and everyone in the conversation is +0 -0 or +1.

Does anyone object to changing this (just the main branch name from master to main)?

It looks like it's not particularly hard technically (+ an update to the collaborator guide and policy). We probably need to address the links as well.

[ronag]

So far no objections and everyone in the conversation is +0 -0 or +1.

What about https://github.com/nodejs/node/issues/33864#issuecomment-643674646?

Also, I think GitHub might pick trunk instead of main. https://github.com/cli/cli/issues/929...

Does anyone object to changing this (just the main branch name from master to main)?

I don't object... but I don't think it's a good idea to rush this...

[MylesBorins]

Fwiw there is quite a lot of work for us to do in order to make sure we do this in a way that is not disruptive.

To @AshCripps point, we definitely need to do a large audit and preparation before moving forward.

I was putting together some notes yesterday outlining steps to take and what to consider before making a change like this

I'd like to suggest that we pause discussion until Monday and I can come back with a suggestion of what we should audit and steps to follow to do this in a way that would minimize disruption

[benjamingr]

@ronag that message was posted after I started writing mine so I did not see it. Sorry for the (timing) confusion. Fwiw https://github.com/nodejs/node/issues/33864#issuecomment-643674646 isn't a conceptual -1 it's a -1 until a plan is drawn for how we make the changes. I thought that not making the change quickly without discussing this or laying out how (clearly) is a given.

[ARitz-Cracker]

Needlessly censoring words does nothing to resolve the social issues surrounding them. The reasoning behind this is the same used when changing the gun emoji to a squirt gun. But in the end, such efforts only take away words and symbols we can use to easily describe concepts, such as the hierarchical and control structures we work with every day. It's destructive at worst and pointless virtue signalling at best.

[ARitz-Cracker]

Anyway, -1 to this. Not worth the effort.

[mscdex]

I am -1 on renaming/changing the branch.

[gabrieledarrigo]

-1 on this.

[jasnell]

Putting this on the tsc agenda for discussion

[gireeshpunathil]

-1 on renaming the branch

[benjamingr]

I would recommend we escalate this (to a vote for example) when:

• We have a clear plan on how to make this change addressing the raised issues (GH links, build infrastructure etc).
• We have an individual or group willing to champion those changes.

Can either of the collaborators -1ing (@gireeshpunathil / @mscdex ) speak up regarding what in particular they are objecting to? (The process of changing it? the name main itself?)

[benjamingr]

Also, this issue is locked because it has received a large number of abuse comments. Like the website change - changes with this flavor tend to get a lot of attention.

[bnoordhuis]

I can come back with a suggestion of what we should audit and steps to follow to do this in a way that would minimize disruption

@MylesBorins Also think about how to roll back when things go wrong. Auditing Jenkins jobs is the kind of mind-numbing tedium that makes human error more likely than not.

[mscdex]

@benjamingr I don't think such a change is necessary and by making such a change it would be creating a lot of technical issues. I've never heard anyone seriously say they found the branch name offensive since git's inception, much like I've never heard anyone seriously find similar terminology offensive elsewhere in computing in the many decades it's been in use.

I believe attaching a single context to such technical terminology (that involves inanimate things) is not useful. Instead, everyone should be focusing their time and effort on things in the world that are actually and obviously offensive.

[jasnell]

@mscdex

much like I've never heard anyone seriously find similar terminology offensive...

That's literally what you're seeing here. Keep in mind that what you might consider "actually" and "obviously" offensive will differ significantly from what others may find "actually" and "obviously" offensive.

[jasnell]

There are definitely some very real and difficult technical challenges to address here. My suggestion would be to make this a strategic initiative with the first step being to establish precisely how to make this change with the least amount of disruption.

[gireeshpunathil]

As a community that has pledged for inclusivity, it is natural to be sensitive and sympathetic to the current situations. However, I guess taking a step back and looking at things from a more wider perspective, I would ask these questions myself, in order:

• Is Node.js community well represented by race, gender, ...? any process change required for the membership criteria for better inclusion of under-represented groups?
• Is Node.js leadership well represented by race, gender, ...? again, any process change required?
• Is Node.js process and practices designed to be inclusive, and is it working well? a retrospective session with commitment to acting on the results?
• Is Node.js nomenclature, words used etc. free from offensive terms? (items such as this)

Doing the naming change first - easy, but causes turbulence in the eco-system, plus gives an impression that we are good with the rest (it is so possible that we are doing good there, but we haven't inspected). Addressing the other things - difficult and time consuming, but addresses the root of the issue from systemic perspectives.

I am willing, and eager to taking part, and / or driving such initiatives, if there is a consensus on Let us do these things first, and attack this later!!!

[mscdex]

That's literally what you're seeing here.

Are you referring to the OP? If so, that didn't exactly strike me as someone saying they personally find the term offensive. To me the issue text read more like "hey, other people are making this change in other projects, should we do it too?".

Keep in mind that what you might consider "actually" and "obviously" offensive will differ significantly from what others may find "actually" and "obviously" offensive.

Here "actually" and "obviously" was meant to describe things that a greater majority of people can agree are offensive.

[addaleax]

To make it explicit, I am strongly +1 on doing this. This is not mutually exclusive with other initiatives in any way.

As for the technical issues, we can either wait to see if something comes from Github, or implement tooling ourselves that would keep the current branch name synced/as an alias, for example.

[MylesBorins]

I'd like to echo the sentiment from @addaleax that changing the branch name need not be mutually exclusive from other changes which our project likely needs to do to be more welcoming / inclusive. We should always be examining our process and thinking about what we can do to improve and make small iterative changes towards where we want to be.

The term master for the main tracking branch is something that has always bothered me. To push back against any narrative that might claim that changing the name of the branch is a fad I'd like to point to https://github.com/mylesborins/node-osc which is one of my more popular modules. I have been using the name current rather than master for over a year. The only reason why I had not brought up making this change at the project was because I didn't think it would have the momentum to be successful, not because I didn't believe that this change should be made.

@mscdex do you have specific technical failures you are concerned will happen? Would an in depth transfer that speaks to all of those changes put your mind at ease? If there was a way to ensure that anyone attempting to push or work with master in the future would be gracefully redirected by GitHub help to ease those concerns (this is a feature I'm poking at internally to see if it can be offered).

I believe attaching a single context to such technical terminology (that involves inanimate things) is not useful. Instead, everyone should be focusing their time and effort on things in the world that are actually and obviously offensive.

We debated extensively about naming API surfaces, why should this be any different? We accepted a default and those helping to create that default are saying "hmm, maybe we should reconsider this". Even if you don't find it useful to attach that context does that fact that others do, and in turn it makes them less productive at what they do, not resonate with you?

Doing the naming change first - easy, but causes turbulence in the eco-system, plus gives an impression that we are good with the rest (it is so possible that we are doing good there, but we haven't inspected). Addressing the other things - difficult and time consuming, but addresses the root of the issue from systemic perspectives.

@gireeshpunathil I'm having a really hard time parsing the logic here. It seems like you are saying that because making this change will be easier than other changes will imply there is no other work to be done? I don't think anyone is saying that at all. What I do see people saying is that this is a small incremental change, that will take quite a bit of work to do properly... but one that I think will be meaningful to various members of our community.

FWIW I've been thinking quite a bit about our governance model, and more specifically consensus seeking, to examine if it is the best governance model for an inclusive environment. I proposed a openjs world summit session to discuss it as well!

I truly think that making positive social change is an ongoing effort that requires constant small change in the right direction. In fact I would argue that choosing to not make smaller, more obvious, iterative changes (such as changing our default branch) would have the inverse effect of telling people that Node.js is an environment that does not care about this.

[MylesBorins]

Also some interesting references for this discussion

Original Discussion on git mailing list

Proposed change to git to allow overriding the default branch

A contributor from bitbucket stating the github + bitbucket + git are all working on this together

A great twitter thread explaining why making this change is the right choice

A statement from a GitHub employee that main is likely to be the new default

A checklist used by the github cli to change default branch

A tool by @gr2m to automate the process of changing the branch

Discussion about changing defaults in GitLab

[gireeshpunathil]

It seems like you are saying that because making this change will be easier than other changes will imply there is no other work to be done?

@MylesBorins - that was an addendum. My main point is that the other items that I listed are more tangible, personal and direct to the people / group who are subjected to the theme in question, and hence present a natural order to address.

I now see your submission in collab summit, and acknowledge it as part of a constant attempt towards improving our community, in the context of diversity and inclusivity! thank you!!

[bnb]

Not a TSC member, but I am a +1 to this change, echoing @addaleax and @MylesBorins sentiments that these do not need to be synchronous changes but can be done simultaneously as we do more intensive work.

For full transparency, I've also brought up the possibility of doing this with all repos under the @nodejs/community-committee.

[gdams]

I'm -0 to this change, Many open source project are considering this change but I'm very fearful of all the changes to scripts/automation. As @MylesBorins mentioned, we will need to do a full audit before considering this change. I'd also suggest pushing out a blog post/tweets detailing the changes several weeks before we make the switch in order to give developers a chance to migrate any tooling that they're written.

[mhdawson]

I do want to see what lead GitHub takes in making this easier

[MylesBorins]

I found a great guide on ways to handle the branch-rename as well as paths towards gradual migration. Will likely be experimenting with some of this stuff on a personal repo over the next two weeks.

https://github.com/chancancode/branch-rename/#gradual-migration

[bnb]

Just a note with some tooling I'm seeing come up around this:

• @gr2m (former CommComm member and long-term ecosystem ecosystem member) is working on a GitHub bot. He's talked a bit about it on Twitter and has a repo.
• github-default-branch allows you to change the default branch for one or many repos via CLI.
• retarget_prs allows you to retarget PRs from one branch to another. It was built by one of the PMs on npm / maintainers of libgit2.

[benjamingr]

Just a note with some tooling I'm seeing come up around this:

What would really help is a way to have master automatically mirror (as in both read and write) main for a transitional and possibly long amount of time and point new users and tools towards main while gradually and at a very comfortable pace pace migrating all the existing infrastructure, docs, guides and tooling.

I'm not sure if that's possible (or hard) as I'm far from an expert or tooling - but such a tool doesn't sound particularly hard to make conceptually. I think the guide Myles linked to provides one such way (via GitHub actions) that might be appropriate.

Links on GitHub would also probably need to automatically redirect somehow.

[MylesBorins]

So we can change any links referring to master to refer to HEAD and they will "just work" with whatever our default branch is. The branch-rename repo I pointed at has an action for mirroring master / main

https://github.com/chancancode/branch-rename/#phase-1-mirror-master-and-main

[MylesBorins]

GitHub has released a repo with official guidance

https://github.com/github/renaming

It mentions a new redirect feature that launched today

Now: supporting early movers 🚚 Some projects on GitHub have already renamed their default branch. As a result, any links to those projects that contained the old branch name would previously have been broken.

So, our first change, shipped on July 17th, updates GitHub.com to redirect links that contain a deleted branch name to the corresponding link in the repository's default branch.

This change supports projects that have already moved. If you haven’t moved yet, we recommend not moving right now, and waiting until later this year. We’re investing in tools to make the renaming the default branch of an existing repository a seamless experience for both maintainers and contributors.

[tniessen]

That's good news, but also means we have to wait "until later this year".

[MylesBorins]

We can run a test, but when I changed a repo on Friday the redirect was working.

We could test this on another repo in the org first.

I can also follow up with that team internally and see if we can get it turned on for us.

[ljharb]

I've seen comments that indicate that blob links redirect but tree links don't (or the reverse); so it may not be a complete feature yet.

Given the large number of open PRs on this repo, it seems like "silently retargeting open PRs" would be a pretty helpful feature to have too.