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?

[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 #33864 (comment)?

Also, I think GitHub might pick trunk instead of main. cli/cli#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 #33864 (comment) 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.

[ljharb]

One thing to check is - in the prompt to do the renaming, it tells you how many PRs it will migrate. If that number doesn’t match the number of open ones, then those not included will be irrecoverably closed. This may be fine, maybe not, but it’s something to be cautious of. (it usually applies when the PR author has not checked “allow edits”, or, when they’ve deleted their fork). The person doing the migration won’t get notifications of the PR closures, but other watchers of them will.

[targos]

[ljharb]

That's not bad! Only 3 will end up being closed. Sadly there's no easy way to find those without looking through every open PR.

[bnb]

Maybe @bnb could you take a stab at this?

any specific ideas on what needs to be done here? Happy to help of course.

I think the big thing is that we'll all want to be ready to help out when something inevitably breaks because master is hardcoded. Looking through a very unsophisticated GitHub Search, we do have a lot of master in the codebase and some of them definitely seem to be referring to branches, including in python and Markdown. I think Markdown should be an easy fix in the future, but it's something that will need to be done.

[mcollina]

any specific ideas on what needs to be done here? Happy to help of course.

No idea tbh :(. We really need a champion for this.

[mhdawson]

I worked through most of the repositories so that we now have all but 6 out of over 100 moved over - see #33864 (comment) for the checklist.

The remaining ones are more complicated in that there are external dependencies. I know that @richardlau has volunteered to look at some of them.

I've not had any cycles lately to loop back and see where we have made process/try to unblock. @bnb that is where a champion who can take a look at the overall picture, do want's need for the remaining repos or find volunteers for the remaining 6 could really help to close it out.

[mhdawson]

These are the repos that still need a rename:

• build:master - Rename primary branch to main build#2761
• i18n:master - Rename primary branch to main.  i18n#502
• node:master
• node-gyp:master - Rename primary branch to main node-gyp#2495
• snap:master - chore: change default branch to main snap#17
• unofficial-builds:master - Rename primary branch to main unofficial-builds#35

[mhdawson]

Poked the issues for i18n, node-gyp, and unofficial-builds.

[targos]

https://github.blog/changelog/2022-05-05-block-creation-of-branches-that-have-matching-names/

🎉 (2)

[ChALkeR]

While https://github.blog/changelog/2022-05-05-block-creation-of-branches-that-have-matching-names/ doesn't restrict admins/owners, requiring signed commits should block accidental branch recreation, as not all of the commits in the history are signed. I checked that it works on https://github.com/nodejs/Gzemnid/settings/branch_protection_rules/25690377

[targos]

Nice workaround!

[mhdawson]

@nodejs/node FYI we are planning to rename the primary branch for nodejs/node to main on Wednesday June 15 ~ 10 ET. This will require that people do the following with respect to local clones. The info from GitHub:

Your members will have to manually update their local environments. We'll let them know when they visit the repository, or you can share the following commands.
git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

[richardlau]

@nodejs/node FYI we are planning to rename the primary branch for nodejs/node to main on Wednesday June 15 ~ 10 ET. This will require that people do the following with respect to local clones. The info from GitHub:

Your members will have to manually update their local environments. We'll let them know when they visit the repository, or you can share the following commands.
git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

cc @nodejs/collaborators

[mcollina]

wow, this has been a long time coming, congrats on the perseverance!

[mhdawson]

@richardlau thanks for adding the at mention :)

[joyeecheung]

Just noticed that we don't have a calendar event for the renaming (was trying to find the exact time in the calendar). It probably would be somewhat useful to create an event in the project calendar for this.

[joyeecheung]

BTW for those who uses node-core-utils, you can use ncu-config to update your local config once the renaming happens:

$ ncu-config set branch main

[mhdawson]

@joyeecheung added to the project calendar. For everybody it's this Wednesday June 15th.

[mhdawson]

About to do the rename

[mhdawson]

We went through and updated ~100 jobs, now testing a few key ones.

[mhdawson]

Re-ran steps to check all repos in the node.js org above (#33864 (comment)) and they look good:

[midawson@midawson rename]$ node doit.js

• .github:main
• Gzemnid:main
• Release:main
• TSC:main
• abi-stable-node:doc
• admin:main
• bot-love:main
• branch-diff:main
• build:main
• build-toolchain-next:main
• changelog-maker:main
• ci-config-github-actions:main
• ci-config-travis:main
• citgm:main
• cjs-module-lexer:main
• code-and-learn:main
• commit-stream:main
• core-validate-commit:main
• corepack:main
• create-node-meeting-artifacts:main
• devcontainer:main
• diagnostics:main
• docker-node:main
• email:main
• eslint-plugin-nodejs-internal:main
• examples:main
• full-icu-npm:main
• full-icu-test:main
• getting-started:main
• github-bot:main
• gyp-next:main
• hardware:main
• help:main
• http-next:main
• http-parser:main
• i18n:main
• icu4c-data-npm:main
• js-native-api-test:main
• llhttp:main
• llnode:main
• llparse:main
• llparse-test-fixture:main
• loaders:main
• loaders-test:main
• lts-schedule:main
• make-node-meeting:main
• meeting-picker:main
• modules:main
• nan:main
• next-10:main
• node:main
• node-addon-api:main
• node-addon-examples:main
• node-api-headers:main
• node-auto-test:main
• node-code-ide-configs:main
• node-core-test:main
• node-core-utils:main
• node-gyp:main
• node-meeting-agenda:main
• node-pr-labeler:main
• node-review:main
• node-v8:main
• node-version-jenkins-plugin:main
• node.js.org:gh-pages
• nodejs-collection:main
• nodejs-dist-indexer:main
• nodejs-ko:main
• nodejs-latest-linker:main
• nodejs-nightly-builder:main
• nodejs.dev:main
• nodejs.org:main
• official-images:main
• package-maintenance:main
• post-mortem:main
• promises-debugging:main
• readable-stream:main
• release-keys:main
• reliability:main
• remark-preset-lint-node:main
• repl:main
• security-wg:main
• snap:main
• social-media-delegates:main
• social-team:main
• string_decoder:main
• tap2junit:main
• tooling:main
• tweet:main
• undici:main
• unofficial-builds:main
• uvwasi:main
• version-management:main
• web-server-frameworks:main
• webidl-napi:main
  [midawson@midawson rename]$

[mhdawson]

Good on the pkgjs branch as well

midawson@midawson rename]$ node doit.js

• .github:main
• action:main
• action-import-blocklist:main
• create:main
• create-package-json:main
• dependents:main
• design:main
• detect-node-support:main
• meet:main
• membership-updater:main
• nv:main
• parseargs:main
• statusboard:main
• support:main
• support-separate-repo:main
• triagebot:main
• wiby:main
  [midawson@midawson rename]$

[MylesBorins]

AMAZING!!!

[bnb]

🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

[trivikr]

🙌 🙌 🙌

Can we unlock this issue?

@mhdawson can provide a public update and close it!

[aduh95]

I don’t think unlocking the issue is necessary at this point. If the branch rename is causing an issue, I’d recommend opening a new issue instead.
it feels good to click on the “Close as completed” button for this one, thanks to everyone who worked on making it happen 🚀

[mhdawson]

We've completed running some tests and all looks ok at this point. We are not aware of any issues at this point.

This was a long an incremental effort (almost 2 years) and I'd like to thank @richardlau and @sxa who helped me do some of the tricker/more complicated repos. It was easier to do those as a group than it would have been for any one person on their own. Also thank to all of the other collaborators who supported in ways from finding a way to prevent accidental pushes of the old branch to quickly responding to issues suggesting the rename in repos across the nodejs org.

I'd also like to thank Red Hat management who early in the larger discussion on renaming primary repos across the GitHub ecosystem not only supported but asked teams to help open source communities make the change.

[sxa]

Added fix to node-stress-single-stress today which had a reference to the old name hiding in an advanced panel in the jenkins UI :-)

[benjamingr]

Have to add that given the change size and my initial skepticism about it being a smooth transition - ±20 days later it has been a pretty smooth transition from a collaborator's PoV (at least mine) so props to whomever ensured that and made sure that this change could happen without interruptions.