Re: Rename offensive terminology (master)

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Tue, Jun 16, 2020 at 07:38:33AM -0400, Whinis wrote:
> > 
> > This sickens me.
> Not just that, any twitter use can complain and get entire communities to
> throw out all rules on changes to appear to be on the "right" side. If
> anyone submitted a patch to change any functioning name without good reason,
> especially one assumed to never change and would likely break a significant
> number of external processes it would be denied without second thought. Here
> the entire thread didn't ask should we change it but instead started on the
> premise, even though this is documented throughout the world and millions or
> even billions of scripts and programs assume it to be constant, it must
> change without discussion.

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

Here are facts:

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.

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")

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.

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.

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.

   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 invite anyone to show just how any of the above is unreasonable.

-K