Re: Rename offensive terminology (master)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 9 Jun 2020 at 18:05, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Simon Pieters <simon@xxxxxxxxxx> 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.
>
> 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).

I work on two git repos where we renamed "master" to something else.
Both have been in heavy use for years, and I don't recall ever hearing
about any issues related to the branch rename except in dumb scripts.
FWIW we renamed because we felt talking about the "master branch" in a
distributed context would lead to confusing expressions like "the
master master". Using something else avoids this double word
formulation.  I definitely find it less confusing when talking about
the branch topology of these repos as opposed to the defaults.

Yves






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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux