Re: Rename offensive terminology (master)

From: demerphq <demerphq@gmail.com>
Date: Jun 18, 2020, 07:57 UTC
Message-ID: <CANgJU+WbPgSTxQ=G3sFSvNFQ1cL3onYk5yKLBR=3AqWeEUCfZQ@mail.gmail.com>
In-Reply-To: <20200617201709.GB86579@google.com>

On Wed, 17 Jun 2020 at 22:17, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 35 quoted lines

>
> Jonathan Nieder wrote:
> > Junio C Hamano wrote:
> >> demerphq <demerphq@gmail.com> writes:
>
> >>> kind of confusion. Consider how this conversation goes for us:
> >>>
> >>> A: "No you need to fetch trunk from the remote, then you need to merge
> >>> it to your local trunk and then push it to the master trunk".
> >>> B: "Ok."
> >>
> >> Hmph, why isn't the last one "trunk trunk"?
> [...]
> >> What I am trying to get at is, after changing the name that is given
> >> by default to the primary branch in a newly created repositories by
> >> "git init" to 'main' (which I am OK with, and it seems that the
> >> major projects and repository hosting services will be doing anyway
> >> with or without getting themselves in this discussion on this list),
> >> wouldn't we risk the same "master master" confusion caused by and to
> >> those newer users who learn 'main' is the word given to the primary
> >> thing?
> >
> > I think Yves's point is that when the tool you are building has a
> > component named $FOO, it's confusing to also have a branch named $FOO.
> [...]
> > In particular when building distributed systems, historically it has
> > been common to have one of the components being built be named
> > 'master'.
>
> Of course I missed the other point --- hostnames like master.<domain>
> (e.g., a hypothetical master.kernel.org), refering to the source of
> truth for something that then gets replicated.
>
> I don't think we're likely to see hostnames like main.kernel.org
> because it's just *so generic* as a word.

Yep, you summarized my point well. I would say master.kernel.org is a correct use of the term "master copy", and the use in the branch name is simply not. My "master branch" for git.git is NOT *the* master. It doesn't make sense to call something "master" and say it means "master copy" when there are actually multiple copies of the master. That isn't what "master copy" means.

So I would say that since in practice very often there will exist a repo which is considered to be *the* master copy of the repo having "master" as a default branch name is unhelpful.

And as you say "main" does not have this problem to quite the same extent. Although frankly I could see "main" being a common term in more distributed development processes where there might not be the same concept of a "master" repo, but there might be a "main" repo where people commonly share their work.

Ultimately if I was the decision maker here I would be choosing terms that are as workflow agnostic as I can find. "main", "master" and "primary" are not workflow agnostic, they are if anything a bit workflow opinionated. "trunk" on the other hand seems pretty self-descriptive and doesn't have much baggage. It's bark is worse than its byte however. :-)

cheers, Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"