Re: Rename offensive terminology (master)

[demerphq <demerphq@gmail.com>]

On Wed, 17 Jun 2020 at 21:56, Junio C Hamano <gitster@pobox.com> 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 described was someone pulling from a box they have code on
(which does not have access to the master repository) to the local
repo on their laptop so they can push it to the master repo.

We have a master repo at $work. We use a mixture of centralized and
decentralized dev models. To get your code into production it must hit
the master repository, and it must be in the trunk branch in the
master repository. I imagine this is a relatively common
configuration, and problem in a professional context. Eg, I might be
testing or debugging code on a node that is not allowed write access
to the master repo for security reasons, so I need to pull the code
from there to my local workstation and then push from there to the
master repository. And all too often our people don't use topic
branches for this stuff and just hack on their local copy of trunk. So
from my point of view what I said was absolutely correct.

> > Similarly when the perl project migrated to git we renamed "master" to
> > "blead" to reduce the possibility "master master" confusion.
>
> Or put it differently, "your local master?  remote master?  or the
> primary master?" would be a way to state the phrase A asked in the
> example without renaming the name for the primary branch to 'trunk'.

Well, "primary" is not a terrible replacement term for "master", but
it isn't ideal either, as it also suggests the existence of a usable
secondary, which isn't a correct mental model (for us). Personally I
would eschew "primary" when there isn't a "secondary".

> 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?

Yeah I think it will still cause problems. If it was my call I would
not choose "main" either. Having said that I do think it is a bit
better than "master" however, as it leaves the term "master"
unambiguously about repositories, and it leaves the term "main"
unambiguously about branches.

Also I would argue it is more etymologically correct. I would argue
that the "master" branch in git terminology is NOT really the "master"
unless it is in the "master" repository. "master" in the content of
"master copy" implies "one" (it has to, what do you do if you have two
masters and they aren't the same!), but using it in a distributed
sense for a branch name doesn't imply one, it implies many, so it
really doesn't make a lot of sense.

> Wouldn't you teach your users to fetch 'main' from the remote, merge
> it to the local 'main' and then push it to the 'main' main?

Unfortunately we call our main repo "main.git", so for my workplace
"main" as a default branch name would be suboptimal. We chose "trunk"
because "main", "master", "primary" all have these double meanings. On
the other hand "trunk" is the standard word for the things that
branches grow out of, and in some trees, the branches even can merge
back into the trunk![1] Thus I find it weird it isn't perceived as the
"obvious" choice to solve this problem. That the bulk of the
population chose "main" suggests to me a lack of imagination more than
a reasoned and thought through decision.

Anyway, personally I would say "main" and "master" are both bad
choices for the default *branch* in a tool that is as workflow
agnostic as git is and seems to intend to be. It is relatively
unfriendly to scenarios where there is in fact a "main repo" or
"master repo" . Many people will in practice use git in a relatively
centralized way with at least one repo designated the "main" or
"master" repo for the project, and so you end up with two "master" or
two "main" things that are very different with very different
properties.

So yeah, I would say that "main" is slightly better than "master" but
is still suboptimal from a comprehension point of view, and it is
downright unhelpful for my $workplace (but I recognize that isn't a
problem you should be considering in this discussion.)

Thank you for your time and efforts in dealing with this subject.

cheers,
Yves
[1] https://www.reddit.com/r/mildlyinteresting/comments/25xkg2/a_tree_branch_grows_back_into_the_tree/

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