Re: Rename offensive terminology (master)

From: John Turner <whinis@gmail.com>
Date: Jun 16, 2020, 13:55 UTC
Message-ID: <834b0165-61c7-1313-6bc9-387d8a31ef76@gmail.com>
In-Reply-To: <20200616133054.2caiwqwp5mlmb54a@chatter.i7.local>

> Let's leave emotionally charged rhetoric and discuss this like
> reasonable human beings.

That would be fine except the entire thread is started on emotionally charged rhetoric

> 1. Git is distributed software. It's not a central service and it does
>     not manage any code hosting platforms. It has no control over what
>     Github, Gitlab, whatnot or other decide to do. If you don't like what
>     they are doing, take it up with them and keep it off this list.

Being that the talk of changing the default name has been said to match up with their efforts how can it be kept off the list? Even the initial start to this pointed to other projects as a reason why this should happen. Seems kind of an odd fence to setup whenever nearly everything about this starts with github and other projects.

Show 10 quoted lines

> 2. Branch naming is entirely the choice of individual repository
>     maintainers. Some prefer not to have a "master" branch, and it's not
>     simply because of "political correctness" reasons as everyone
>     insists:
>     
>     - they may prefer to have "stable" and "development" branches
>     - they may want to use localized names for all their naming
>       conventions (using Cyrillic, Hanzi, Kana, whatever)
>     - they may be goofing off (there's a furry-related repository on
>       GitHub with the main branch called "yiffed")

My understanding is you can already delete the master branch and force-push that. So back to this topic why does anything need to change?

Show 8 quoted lines

> 3. In your example, "millions and billions" of scripts are already wrong
>     if they assume that there is always a "master" branch. However, it
>     doesn't matter, because unless someone actively renames a branch in
>     an existing repo that they work with, they will continue working just
>     fine. Nobody is talking about banning the use of the word "master"
>     for any existing branches. I am 100% certain that Linux mainline will
>     continue to happen in refs/heads/master, because the fallout of
>     renaming that would be terrible.

They may be wrong but being while Git is not a central service is is used in millions of organizations and by millions of organizations through central services such as Github. Through this distributed use some things are assumed whenever creating new repositories and yes the master branch is one of these. Nearly every tutorial on Git or using get will reference the master branch and its is how many people learn. Its already been shown in the patch how these changes might break on existing repos due to assumption of the main/master/primary/<insert word here> branch is no longer what it used to be leading to a need to fix all configs on all repos. Also it has been pointed out how disconnects between configs between two different clones could lead to issues.

Requiring every organization or individual who uses Git to entirely retool due to changes in a base assumption is the exact opposite you want of any stable software. The claim that this only affects new repositories so its immaterial is an odd foot to stand on being that almost all of these scripts assume something about new repositories that will now be different.

> 4. In Git, local branch names do not need to map to remote branch names.
>     Your local branch "upstream" can track remote branch "development".
>     If the remote branch gets renamed, you simply update your
>     configuration and continue without change.

While true this is more of an advanced feature that many users don't know about. Saying that its ok because you can fix it with something more complicated sounds like the worst possible reply.

Show 8 quoted lines

> 5. The change proposal has two parts to it:
>
>     1. Allow users of Git to designate another branch as their primary.
>        As Junio pointed out, Git treats one of the branches as special,
>        but currently that is hardcoded to "master". This change will make
>        this configurable so that projects with different naming
>        conventions can designate some other branch as their primary.
>        I've seen no objection to this from anyone.

There should be an object to any major change to the underlying code such as this without good reason for doing such. Being that this is not a security issue and as you have pointed out people can already name their branches whatever they like its adding complexity to an already complex system. Being that we are as you say detaching this from "emotionally charged rhetoric" and being "reasonable human beings." what good reason is there to introduce such complexity if users appear to overall not want it and those that do already have an alternative?

Show 7 quoted lines

>     2. Consider if the default branch created during "git init" should be
>        called "master" or if it should be called something else. Options
>        are to keep it "master" for legacy reasons or to make it something
>        more descriptive like "main". Since this would be merely the
>        default configuration option, packagers and sysops can set it to
>        be whatever they like via /etc/gitconfig, and individual
>        developers can set this in their ~/.gitconfig.

I have seen no one in this email chain nor the one asking for what the default name should be even entertain the idea that it should be left at all. Nor have I seen any attempts to accept reasoning for why it shouldn't change. Changing the default while seemingly simple can have long reaching consequences as anyone in development would know. Claiming its merely a default is rather disingenuous for a piece of software as widely used as Git.

I leave with this, if we are to leave out the emotions what good reason is there to push through this change?

-whinis