Re: Rename offensive terminology (master)

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