Re: Rename offensive terminology (master)

[John Turner <whinis@gmail.com>]

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

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

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


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

>     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