Re: Changing "master" to "main"/"trunk"?

1,003 views
Skip to first unread message

Yoav Weiss

unread,
Jun 11, 2020, 3:39:46 AM6/11/20
to blink-dev, infr...@chromium.org, chromium-dev

On Thu, Jun 11, 2020 at 9:17 AM Yoav Weiss <yo...@yoav.ws> wrote:
Hey all,

Following some online conversations, I became aware that git's "master" branch is a reference to the (offensive and bad) "master/slave" analogy.

That made me wonder if we could perhaps move away from that terminology in the Chromium project. 
While I'm sure this will have some cost (e.g. reconfiguring all the bots), continuing to type `git pull origin master` all day after being aware of the origin feels odd to me, and must not be great to folks who are more directly impacted by the analogy.

Thoughts?

Cheers,
Yoav



Message has been deleted

Mike Frysinger

unread,
Jun 11, 2020, 4:12:34 AM6/11/20
to yo...@yoav.ws, blink-dev, infra-dev, chromium-dev
Chromium colloquially uses "tip of tree" / "tot" to refer to the latest tree state rather than referring to specific branch names.

devs typically interface with gclient & git cl which hides a bit of the underlying branch names (as not all projects use "master" when they create forks).  i don't think that example command is commonly used or needed (since one can just `git pull` or `git fetch`).  it doesn't mean people wouldn't come across it in other situations (e.g. Gerrit UIs), but it isn't something devs would be typing "all day".  i don't know that i've ever run that exact command tbh in any project as the defaults or config files handle it.

given enough effort, anything is possible, but switching branch names will not be trivial, and would diverge from standard git conventions in the wider world.  so while i don't disagree with the underlying reasons, i'm not sure how feasible it would be for something so entrenched like this.
-mike

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACj%3DBEgrTC34LL8DneaWeaw22T8RozxMKDTkTOhDGSFYjU15%3DA%40mail.gmail.com.

Daniel Cheng

unread,
Jun 11, 2020, 4:53:28 AM6/11/20
to Mike Frysinger, Yoav Weiss, blink-dev, infra-dev, chromium-dev
When I check out new branches, I frequently have them tracking ToT, which means origin/master in practice. So while it might not be something I type every day, it's definitely something that comes up at least a few times a week. It also shows up in the gerrit UI and when browsing via gitiles.

Switching everything over definitely does seem painful, but it could probably be done over time to allow a staged migration?

Also, I believe git is considering a conference on inclusive language in Git: it might be interesting to see what comes out of that.

Daniel

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAbOSckN%3Dtk0pbQp6VmZ45sya6SoPYcAtRysJ7L6LbMjgoKFjQ%40mail.gmail.com.

Nodir Turakulov

unread,
Jun 11, 2020, 5:11:20 AM6/11/20
to Daniel Cheng, Jonathan Nieder, Mike Frysinger, Yoav Weiss, blink-dev, chromium-dev, infra-dev
+jrn

You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAF3XrKqZQVGYb4q%3DE_-Q0D%3DoUd8A3-0vJ%2BX0bhRpfaGs8ZRWxQ%40mail.gmail.com.
--
My work hours are weird because I WFH with a toddler. Please don't feel obliged to reply straight away.

Primiano Tucci

unread,
Jun 11, 2020, 5:45:59 AM6/11/20
to Nodir Turakulov, Daniel Cheng, Jonathan Nieder, Mike Frysinger, Yoav Weiss, blink-dev, chromium-dev, infra-dev
My $0.02:
You can rename the default branch to something else and point HEAD to something else, but any script that happens to rely on the default fall back on "master" will break. 
"Master" is baked everywhere in git, from git books down to the implementation.
Renaming "master" to something else is asking for really a lot of trouble. I'd expect a large number of scripts and pieces of infra to fall apart and require several days to fix if you rename that.


Yoav Weiss

unread,
Jun 11, 2020, 5:46:33 AM6/11/20
to Daniel Cheng, Mike Frysinger, blink-dev, infra-dev, chromium-dev
On Thu, Jun 11, 2020 at 10:51 AM Daniel Cheng <dch...@chromium.org> wrote:
When I check out new branches, I frequently have them tracking ToT, which means origin/master in practice. So while it might not be something I type every day, it's definitely something that comes up at least a few times a week. It also shows up in the gerrit UI and when browsing via gitiles.

Switching everything over definitely does seem painful, but it could probably be done over time to allow a staged migration?

Also, I believe git is considering a conference on inclusive language in Git: it might be interesting to see what comes out of that.

That's encouraging! :)

Torne (Richard Coles)

unread,
Jun 11, 2020, 10:51:32 AM6/11/20
to Primiano Tucci, Nodir Turakulov, Daniel Cheng, Jonathan Nieder, Mike Frysinger, Yoav Weiss, blink-dev, chromium-dev, infra-dev
Most of the references in git's implementation are comments, documentation, test code, and svn integration. As far as I've seen from other discussions on this, looking through the code, and making the change in other repos I control, it only really appears to be "significant" in two cases: the default target of the HEAD symref after creating a new repo with `git init` (which isn't particularly relevant outside of the context of actually creating an entirely new repo, and can be overridden by defining a different default template directory that points HEAD somewhere else), and the default remote branch to use when adding a submodule without explicitly specifying the branch (but we generally don't use submodules). In basically all other contexts the default branch for a remote is just whatever HEAD points to. So yes, I'm sure it would be disruptive for our infrastructure/scripts that may reference master instead of using HEAD, but there don't really appear to be any significant problems caused by git's own implementation.

Where I've seen people making this change "main" is a popular choice since it tab-completes from "ma". You can also get a good measure of backward compatibility (though I'm not sure it works exactly as desired in all contexts) by just having both HEAD and refs/heads/master be symrefs to refs/heads/main - this means that "git clone" and similar operations will operate on "main" but explicitly specifying master will still work. (and vice-versa you can symref main to master in repos where renaming master is too disruptive). Doing it incrementally for new repos might be an option though having a mixture is also potentially confusing..

(incidentally a nice reference for how to configure `git init` to use a different default name via a template directory is https://danieltull.co.uk/blog/2020/06/08/renaming-gits-default-master-branch/ - I use this so that any new repos I do create for any project start out this way, even if it's not always simple to rename it in existing projects)

Jeffrey Yasskin

unread,
Jun 11, 2020, 1:54:03 PM6/11/20
to Yoav Weiss, blink-dev, infr...@chromium.org, chromium-dev
+1 and thanks for bringing this up! I've switched to 'main' instead of 'master' for all my new repositories, and the only problem I had was fixed by https://crbug.com/1023031. The Privacy CG is also mostly using `main` or `gh-pages` as their default branch, with a template repository to help people remember. https://github.com/martinthomson/i-d-template/blob/master/doc/REPO.md#fast-setup also recommends `main` for new IETF drafts. I haven't heard of any problems with any of those repositories.

I haven't yet switched any existing repositories for fear of breaking existing PRs and the branch relationships in people's checkouts. I suspect the infrastructure team could modify `gclient rebase-update` to automatically follow changes in the identity of upstream HEAD, and we'll probably need changes in Gerrit and a lot of the testing and release machinery, but I hope the infrastructure team can find time to make those changes.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Dirk Pranke

unread,
Jun 11, 2020, 5:23:23 PM6/11/20
to Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
Hi all,

[putting on my community@ hat, although this also reflects my own thinking ...]

I think it's a reasonable suggestion to switch away from "master". 

To head off one particular potential line of criticism up front: from what I can tell, Git uses the word in the sense of "master" as an adjective, which is as a synonym for "main" or "principal"; it does not use the word in the more problematic sense of master/slave (like buildbot did). However, I think it still comes from the same etymological roots, so I am not suggesting that it's not problematic at all. 

And, I would also view this as a dumb thing to put up a fight over since the obvious synonyms would be equally if not more descriptive, and probably less problematic.

But, as others have pointed out, changing this is not trivial, either. It is real work for us to go through and figure out what all would need to change and what the best ways to do that would be, let alone actually do that work. I think that's work we should strongly consider doing, and I'll take it up with the Ops leads to discuss this (since the Ops team would likely have to do the bulk of the work here).

One thought that comes to mind, is that we in Ops have from time to time talked about how it would be nice if Git had more fully worked out support for symbolic references. For example, it would be nice if we could have a "beta" branch ref that floated to follow whatever branch was currently the beta branch for Chrome. [ That particular example has challenges in practice, but hopefully you get the point ]. At any rate, if it did, then we could create a "main" or "trunk" alias for "master" and maybe that would really help with the transition, and also potentially result in a win-win for the git community as well. So, we can follow up on this with the git-core team, too. [ Disclaimer: I don't know that this is actually a good idea, maybe it isn't. ]

Let me take up these things, and I'll report back when I have more to share.

-- Dirk

You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CANh-dXm7%2Bu4pEvMKK0qY%2Bf95SN6xM4d1r50XfEmwBrtL8u%3DO1w%40mail.gmail.com.

Joe Mason

unread,
Jun 11, 2020, 6:20:41 PM6/11/20
to Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
The linked tweet points out that git's use of "master" seems to have been copied directly from BitKeeper's, which was explicitly used for master/slave repositories (https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html). So the origin is in fact from the master/slave terminology. On the other hand git's use of it doesn't directly reference the master/slave relationship anymore, it's just been copied without thought, so it doesn't "mean" that now. On the gripping hand, what mostly matters is people's reaction to the term which is the same no matter what the origin was.

What about making refs/heads/main a symref to refs/heads/master, and encouraging use of "main" instead of "master" in documentation and new scripts? That way existing scripts won't break but most people won't have to encounter the term in normal work.

As an aside, is there any plan to rename https://cs.chromium.org/chromium/build/scripts/slave/? I assume the amount of work involved there is a hurdle as well.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTDDn_QYmQ34ZZBG%2B%2BnHRLLqxDSRKpsQwWyzK-WwcpC_cw%40mail.gmail.com.

Stephen Martinis

unread,
Jun 11, 2020, 6:53:32 PM6/11/20
to Joe Mason, Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
On Thu, Jun 11, 2020 at 3:20 PM 'Joe Mason' via Chromium-dev <chromi...@chromium.org> wrote:
The linked tweet points out that git's use of "master" seems to have been copied directly from BitKeeper's, which was explicitly used for master/slave repositories (https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html). So the origin is in fact from the master/slave terminology. On the other hand git's use of it doesn't directly reference the master/slave relationship anymore, it's just been copied without thought, so it doesn't "mean" that now. On the gripping hand, what mostly matters is people's reaction to the term which is the same no matter what the origin was.

What about making refs/heads/main a symref to refs/heads/master, and encouraging use of "main" instead of "master" in documentation and new scripts? That way existing scripts won't break but most people won't have to encounter the term in normal work.

As an aside, is there any plan to rename https://cs.chromium.org/chromium/build/scripts/slave/? I assume the amount of work involved there is a hurdle as well.
I'm working on doing that. It's a bit of a pain, since we need to update references to that, and there are internal repos which also would be affected.  

Dirk Pranke

unread,
Jun 11, 2020, 6:58:06 PM6/11/20
to Joe Mason, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
Hi,

First, I want to apologize to everyone for my previous note. I didn't think it through well, and I shouldn't have blurred whatever the community@ position might be and what my personal beliefs were. 

I'll try to keep those more separated and apparent going forward ...

On Thu, Jun 11, 2020 at 3:19 PM Joe Mason <joenot...@google.com> wrote:
The linked tweet points out that git's use of "master" seems to have been copied directly from BitKeeper's, which was explicitly used for master/slave repositories (https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html). So the origin is in fact from the master/slave terminology. On the other hand git's use of it doesn't directly reference the master/slave relationship anymore, it's just been copied without thought, so it doesn't "mean" that now. On the gripping hand, what mostly matters is people's reaction to the term which is the same no matter what the origin was.

Ah, good to know, I wasn't aware of that history, and hadn't looked at the tweet, which is another mistake on my part :(.
 
What about making refs/heads/main a symref to refs/heads/master, and encouraging use of "main" instead of "master" in documentation and new scripts? That way existing scripts won't break but most people won't have to encounter the term in normal work.

I'm not entirely sure how well symbolic refs work, and so I'm not sure if this will work reliably in all of the contexts we need it to. It may be that I'm Holding It Wrong, though.

So, this is something I'd want to investigate and discuss with our git gurus.

As an aside, is there any plan to rename https://cs.chromium.org/chromium/build/scripts/slave/? I assume the amount of work involved there is a hurdle as well.

Yes, we very much want to get rid of this, as Stephen just noted.

Joe Mason

unread,
Jun 11, 2020, 7:44:27 PM6/11/20
to Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
On Thu, Jun 11, 2020 at 6:56 PM Dirk Pranke <dpr...@google.com> wrote:
What about making refs/heads/main a symref to refs/heads/master, and encouraging use of "main" instead of "master" in documentation and new scripts? That way existing scripts won't break but most people won't have to encounter the term in normal work.

I'm not entirely sure how well symbolic refs work, and so I'm not sure if this will work reliably in all of the contexts we need it to. It may be that I'm Holding It Wrong, though.

So, this is something I'd want to investigate and discuss with our git gurus.

Yeah, that's why I suggested keeping "master" as the real branch name and "main" a ref, instead of changing the real branch name to "main" and making "master" a ref.  Any situation where the ref doesn't work we can continue to use "master" with an apology.

Joe

Aaron Gable

unread,
Jun 16, 2020, 1:30:25 PM6/16/20
to joenot...@google.com, Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
FWIW, 100% in favor of switching from "master" to "main".

Will it be difficult? Eh, depends on your definition.
Will it run into unexpected issues, cause minor breakages, and require ongoing effort until all the scripts which explicitly reference "master" are cleaned up? Of course.
Will it be worth it to remove this unnecessary legacy of our white supremacist past? Also of course.

This is not a situation where one can simply say "eh, the effort is too high, not worth it". We're not comparing engineering hours to dollars or bug escapes or milliseconds here. We're comparing engineering hours to human compassion, empathy, and decency. The latter should take priority.

Aaron

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Dirk Pranke

unread,
Jun 16, 2020, 4:01:09 PM6/16/20
to Yoav Weiss, Chromium-dev, blink-dev, infra-dev, Joe Mason, Jeffrey Yasskin, James Lu, Andy Perelson, Julie Parent, Jason Kersey
Hi all,

I've spoken to the (Ops) team about this and we are going to scope it out and figure out what we can do here. Until we've done that and understood what all might need to change and how we can do so without breaking too many things, I wouldn't necessarily want to commit to the change but we're working on it. Also, given the scope and our existing commitments I wouldn't expect this to get changed before Q3 at least, but I'll let the folks who will actually do the investigation and work take it from here.

Some good news on this front (as many of you will have seen already) is that there is activity on this in the wider Git community (GitHub, GitLab, our Git server team, core Git, etc.) as well. We will definitely work with them to try and figure out a good experience and some consistency.

I've filed crbug.com/1095735 for anyone interested in tracking progress on this to follow along.

@Yoav Weiss, thanks for bringing this up :).

-- Dirk


On Tue, Jun 16, 2020 at 11:04 AM James Lu <jam...@gmail.com> wrote:
I have largely abandoned the idea of a main branch entirely. Every release has its own branch with its own name, to build a release I pull a branch and build it. 
To unsubscribe from this group and stop receiving emails from it, send an email to chromi...@chromium.org.

Steve Kobes

unread,
Jun 16, 2020, 4:56:30 PM6/16/20
to Aaron Gable, joenot...@google.com, Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
On Tue, 16 Jun 2020 at 13:28, Aaron Gable <aga...@chromium.org> wrote:
This is not a situation where one can simply say "eh, the effort is too high, not worth it". We're not comparing engineering hours to dollars or bug escapes or milliseconds here. We're comparing engineering hours to human compassion, empathy, and decency. The latter should take priority.

I have no objection to the change, but I disagree that it is somehow exempt from cost-benefit analysis, and the above framing strikes me as excessively polarizing.  I would hope that the folks who investigate this proposal feel safe raising concerns about its costs without having their values questioned in such absolute terms.
 

Aaron

On Thu, Jun 11, 2020 at 4:43 PM 'Joe Mason' via Chromium-dev <chromi...@chromium.org> wrote:
On Thu, Jun 11, 2020 at 6:56 PM Dirk Pranke <dpr...@google.com> wrote:
What about making refs/heads/main a symref to refs/heads/master, and encouraging use of "main" instead of "master" in documentation and new scripts? That way existing scripts won't break but most people won't have to encounter the term in normal work.

I'm not entirely sure how well symbolic refs work, and so I'm not sure if this will work reliably in all of the contexts we need it to. It may be that I'm Holding It Wrong, though.

So, this is something I'd want to investigate and discuss with our git gurus.

Yeah, that's why I suggested keeping "master" as the real branch name and "main" a ref, instead of changing the real branch name to "main" and making "master" a ref.  Any situation where the ref doesn't work we can continue to use "master" with an apology.

Joe

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH%3DT95SvzmXOjKL12w%3D6TS4Q22xXPDQyNXDQBjemCZa9YvapWw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAD7xkUS6mxOL1gzU5LAXt_KcZ7y4jcEuMb-%3DqYCWdNPLjzX%3D-Q%40mail.gmail.com.

Yoav Weiss

unread,
Jun 16, 2020, 4:57:31 PM6/16/20
to Dirk Pranke, Chromium-dev, blink-dev, infra-dev, Joe Mason, Jeffrey Yasskin, James Lu, Andy Perelson, Julie Parent, Jason Kersey
That's great, thank you!! :)

Matt Giuca

unread,
Jun 17, 2020, 12:58:40 AM6/17/20
to Steve Kobes, Aaron Gable, Joe Mason, Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
On Wed, 17 Jun 2020 at 06:54, Steve Kobes <sko...@chromium.org> wrote:
On Tue, 16 Jun 2020 at 13:28, Aaron Gable <aga...@chromium.org> wrote:
This is not a situation where one can simply say "eh, the effort is too high, not worth it". We're not comparing engineering hours to dollars or bug escapes or milliseconds here. We're comparing engineering hours to human compassion, empathy, and decency. The latter should take priority.

I have no objection to the change, but I disagree that it is somehow exempt from cost-benefit analysis, and the above framing strikes me as excessively polarizing.  I would hope that the folks who investigate this proposal feel safe raising concerns about its costs without having their values questioned in such absolute terms.

+1

I think it's also important to temper this conversation and avoid framing it the use of a word like "master" as the "unnecessary legacy of our white supremacist past". I am supportive of excising symbols of oppression from society, but I would question whether "master" has such a meaning in this context. I have always thought of Git's "master" branch as meaning "the branch that all other branches are copied from", analogous to a film master (from which the term "remaster" is derived). Whether it's acceptable for Git to use a word with overloaded meaning, I won't wade into, but I think we ought to be careful suggesting that things named by our co-workers are "white supremacy" when they are more likely to be innocent usage of heavily overloaded words.

 

Aaron

On Thu, Jun 11, 2020 at 4:43 PM 'Joe Mason' via Chromium-dev <chromi...@chromium.org> wrote:
On Thu, Jun 11, 2020 at 6:56 PM Dirk Pranke <dpr...@google.com> wrote:
What about making refs/heads/main a symref to refs/heads/master, and encouraging use of "main" instead of "master" in documentation and new scripts? That way existing scripts won't break but most people won't have to encounter the term in normal work.

I'm not entirely sure how well symbolic refs work, and so I'm not sure if this will work reliably in all of the contexts we need it to. It may be that I'm Holding It Wrong, though.

So, this is something I'd want to investigate and discuss with our git gurus.

Yeah, that's why I suggested keeping "master" as the real branch name and "main" a ref, instead of changing the real branch name to "main" and making "master" a ref.  Any situation where the ref doesn't work we can continue to use "master" with an apology.

Joe

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH%3DT95SvzmXOjKL12w%3D6TS4Q22xXPDQyNXDQBjemCZa9YvapWw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAD7xkUS6mxOL1gzU5LAXt_KcZ7y4jcEuMb-%3DqYCWdNPLjzX%3D-Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAjAU%3Da4pNS7Uhud-R-FeMq7T81bG-MSjq%2BCLB6CPKhh2DhJ-A%40mail.gmail.com.

Nick Harper

unread,
Jun 17, 2020, 3:04:54 AM6/17/20
to mgi...@chromium.org, Steve Kobes, Aaron Gable, Joe Mason, Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
On Tue, Jun 16, 2020 at 9:57 PM Matt Giuca <mgi...@chromium.org> wrote:


On Wed, 17 Jun 2020 at 06:54, Steve Kobes <sko...@chromium.org> wrote:
On Tue, 16 Jun 2020 at 13:28, Aaron Gable <aga...@chromium.org> wrote:
This is not a situation where one can simply say "eh, the effort is too high, not worth it". We're not comparing engineering hours to dollars or bug escapes or milliseconds here. We're comparing engineering hours to human compassion, empathy, and decency. The latter should take priority.

I have no objection to the change, but I disagree that it is somehow exempt from cost-benefit analysis, and the above framing strikes me as excessively polarizing.  I would hope that the folks who investigate this proposal feel safe raising concerns about its costs without having their values questioned in such absolute terms.

+1

I think it's also important to temper this conversation and avoid framing it the use of a word like "master" as the "unnecessary legacy of our white supremacist past". I am supportive of excising symbols of oppression from society, but I would question whether "master" has such a meaning in this context. I have always thought of Git's "master" branch as meaning "the branch that all other branches are copied from", analogous to a film master (from which the term "remaster" is derived). Whether it's acceptable for Git to use a word with overloaded meaning, I won't wade into, but I think we ought to be careful suggesting that things named by our co-workers are "white supremacy" when they are more likely to be innocent usage of heavily overloaded words.

Given how Git uses the term "master", it's not obvious where its meaning came from. However, the tweet that Yoav linked to (https://twitter.com/mislav/status/1270388517382901766) shows that the use of the term "master" in Git did originate from the master/slave terminology and not the "master copy" metaphor.

(I also support this project to rename "master" in Chromium.)

Albert J. Wong (王重傑)

unread,
Jun 17, 2020, 3:28:45 AM6/17/20
to nha...@chromium.org, mgi...@chromium.org, Steve Kobes, Aaron Gable, Joe Mason, Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
On Wed, Jun 17, 2020 at 12:04 AM Nick Harper <nha...@chromium.org> wrote:


On Tue, Jun 16, 2020 at 9:57 PM Matt Giuca <mgi...@chromium.org> wrote:


On Wed, 17 Jun 2020 at 06:54, Steve Kobes <sko...@chromium.org> wrote:
On Tue, 16 Jun 2020 at 13:28, Aaron Gable <aga...@chromium.org> wrote:
This is not a situation where one can simply say "eh, the effort is too high, not worth it". We're not comparing engineering hours to dollars or bug escapes or milliseconds here. We're comparing engineering hours to human compassion, empathy, and decency. The latter should take priority.

I have no objection to the change, but I disagree that it is somehow exempt from cost-benefit analysis, and the above framing strikes me as excessively polarizing.  I would hope that the folks who investigate this proposal feel safe raising concerns about its costs without having their values questioned in such absolute terms.

+1

I think it's also important to temper this conversation and avoid framing it the use of a word like "master" as the "unnecessary legacy of our white supremacist past". I am supportive of excising symbols of oppression from society, but I would question whether "master" has such a meaning in this context. I have always thought of Git's "master" branch as meaning "the branch that all other branches are copied from", analogous to a film master (from which the term "remaster" is derived). Whether it's acceptable for Git to use a word with overloaded meaning, I won't wade into, but I think we ought to be careful suggesting that things named by our co-workers are "white supremacy" when they are more likely to be innocent usage of heavily overloaded words.

Given how Git uses the term "master", it's not obvious where its meaning came from. However, the tweet that Yoav linked to (https://twitter.com/mislav/status/1270388517382901766) shows that the use of the term "master" in Git did originate from the master/slave terminology and not the "master copy" metaphor.

(I also support this project to rename "master" in Chromium.)

While Aaron's statement is strong, the point is that for some folks, his phrasing is reflective of exactly what this choice represents. This is especially true in the context of recent events. 

To Andreas's point that "you can't just throw away a branch just because someone thinks it's some offensive reference"....actually we can. In fact, that's specifically the choice in front of us.

All that being said, I think we can discuss this with a lower emotional tone.  It's completely within our capability to make this change. It also has a cost. We've evaluating the cost because this is an engineering project and that's what we do. However, I expect we'll find it doable. I mean, this project has a history of doing extremely disruptive things to build systems (gyp, gn, goma, clang moves, etc).

Thus I for one am less scared of the cost and would like to see this change happen.

-Albert

 

Dirk Pranke

unread,
Jun 17, 2020, 2:05:16 PM6/17/20
to James Lu, Albert J. Wong (王重傑), Nick Harper, Matt Giuca, Steve Kobes, Aaron Gable, Joe Mason, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
I suspect we'll end up switching to whatever the industry develops consensus around. At the moment, it looks like that's trending towards "main" as far as I've seen.

I am not interpreting Aaron's post as saying we shouldn't do any cost-benefit analysis at all, rather that the weighting is not simply something where you look at the amount of time required to make the change and compare to a minimal technical benefit and decide we shouldn't do it. We have to weigh in human factors and feelings as well. And I agree with that interpretation. But I also want the team investigating this to feel welcome to look at the request fairly and raise any concerns they have over cost or complexity of approach, and I think they will do so.

-- Dirk

On Wed, Jun 17, 2020 at 9:33 AM James Lu <jam...@gmail.com> wrote:
What if it was called "root"?

Albert J. Wong (王重傑)

unread,
Jun 17, 2020, 2:06:31 PM6/17/20
to James Lu, nha...@chromium.org, Matt Giuca, Steve Kobes, Aaron Gable, Joe Mason, Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
On Wed, Jun 17, 2020 at 9:33 AM James Lu <jam...@gmail.com> wrote:
What if it was called "root"?

So the topic at hand is master vs something else under the the context of 
  • current protests around the world
  • the movement across various bits of the tech industry (including Github) to specifically handle this topic
  • the request having come here
Thus, to me, making comparisons with other terms that do not have similar context and momentum misses the point and mostly confuses the discussion. If we want to consider other teams, I think we should open another thread.

Again though, I will state we've done much harder things than this where the choice to engage was sometimes even just done at the whim of a random developer. (See the creation of Ninja which was basically Evan Martin's personal passion project).

Let's figure out how hard this actually is and ground the topic in that. Again, I predict it's going to be quite doable and that we should do it. But publicly discussing the validity of the concern as a gate to scoping doesn't make sense when so so so many other choices in this project have been made with much less consensus, much less rigor, and much less evidence of impact.

-Albert



On Wed, Jun 17, 2020 at 3:28 AM Albert J. Wong (王重傑) <ajw...@chromium.org> wrote:

Dan Sinclair

unread,
Jun 17, 2020, 2:17:02 PM6/17/20
to Albert J. Wong (王重傑), James Lu, nha...@chromium.org, Matt Giuca, Steve Kobes, Aaron Gable, Joe Mason, Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
If it helps, we made this change in Tint (dawn.googlesource.com/tint) last week. Changing the primary branch in gerrit required all open CLs against the old branch to be closed or abandoned (probably this could be worked around by the infra team? I just abandoned all the open CLs). There is also at least one outstanding issue in depot_tools (http://crbug.com/1094899) where `git cl upload` needs to be `git cl upload origin/main` in order to work at the moment.

Other than that, it's just been finding places in various scripts and configurations where we checked for the explicit branch name and fixing them up.

dan


James Lu

unread,
Jun 17, 2020, 5:30:54 PM6/17/20
to ajw...@chromium.org, nha...@chromium.org, mgi...@chromium.org, Steve Kobes, Aaron Gable, Joe Mason, Dirk Pranke, Jeffrey Yasskin, Yoav Weiss, blink-dev, infra-dev, chromium-dev
What if it was called "root"?

On Wed, Jun 17, 2020 at 3:28 AM Albert J. Wong (王重傑) <ajw...@chromium.org> wrote:

James Lu

unread,
Jun 17, 2020, 5:31:24 PM6/17/20
to Chromium-dev, joenot...@google.com, dpr...@google.com, jyas...@chromium.org, yo...@yoav.ws, blin...@chromium.org, infr...@chromium.org
I have largely abandoned the idea of a main branch entirely. Every release has its own branch with its own name, to build a release I pull a branch and build it. 

On Tuesday, June 16, 2020 at 1:30:25 PM UTC-4, agable wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to chromi...@chromium.org.
Reply all
Reply to author
Forward
0 new messages