Re: Rename offensive terminology (master)

From: Simon Pieters <simon@bocoup.com>
Date: Jun 9, 2020, 20:52 UTC
Message-ID: <CAOAHyQzxG7Lc6+PLBtM6oe9vSoEEAmuXAaKF2VzO_phtkfGRVA@mail.gmail.com>
In-Reply-To: <xmqqeeqoi5wc.fsf@gitster.c.googlers.com>

Hi Junio,

On Tue, Jun 9, 2020 at 6:02 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

>
> Simon Pieters <simon@bocoup.com> writes:
>
> > If someone is interested in helping with this, please follow up with
> > Don. But I would like to ask again for git mainline to seriously
> > consider adopting this change, given the information presented above
> > and the ongoing movement against systemic racism.
>
> I am OK in principle if a future version of Git, when used by a new
> user of Git who does not have any custom configuration, wrote a
> string other than 'master' in .git/HEAD when "git init" is run.
>
> Picking a good replacement word to mean the primary branch is
> tricky, though.  Just having a notion that one is special among
> many (i.e. the primary-ness of the thing being named with a word
> that will replace 'master') may already be offending to some folks.

I find this response not satisfactory:

- as far as I can tell, no evidence that "main" offends anyone.
- git trying to be neutral by not having any default name seems like a
weak response to this issue.
- having users have to pick a branch name when initiating a repo
increases the burden on users and makes the learning curve steeper for
beginners.
- git not being opinionated on the branch name doesn't address the
inconsistency problem pointed out in the original post.
- while git itself could avoid having a default branch name, platforms
that use git such as GitHub or GitLab will still likely want a
default.

I think git can lead the way and make things inclusive, consistent, and not regress on usability.

cheers,

Show 29 quoted lines

> Also notice that the qualified statement above talks only about the
> plain vanilla experience---the change of the default should be
> designed to avoid harming workflows in existing repositories and
> tools built around them.
>
> So, I think there are two separate tasks that can run in parallel.
>
>  * Pick the new default word to replace 'master'; it may turn out
>    that the Git project choose not to pick any to avoid offending
>    anybody, in which case "git init" may force end users pick the
>    default they want to use and offer recording in the ~/.gitconfig
>    file.
>
>  * Engineering work that uses the word that replaces 'master' by
>    default (if one got chosen) when not configured, and use the word
>    the end user chose when configured (iow, allow users to override
>    the default word that will replace 'master').  This includes
>    design work to decide what to do in existing repositories (if
>    there is anything that needs to be done).
>
> Without digging deeply, I think we are pretty good about basing
> things on HEAD (e.g. "git branch -d" protects the branch by seeing
> if it is already merged to 'HEAD' or its @{upstream}, and not treats
> 'master' any specially), so it might be the matter of teaching "git
> init" (it uses 'master' by default) and "git clone" (it tries to use
> the name of the branch the HEAD at origin points at, but falls back
> to 'master' when the branch name their HEAD points at cannot be
> determined).
>

-- Simon Pieters Bocoup https://bocoup.com/

-- 
Simon Pieters
https://bocoup.com/