On Tue, Jun 16, 2020 at 09:55:29AM -0400, John Turner wrote: > > 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? And people indeed do that as this thread point out. Git can do better supporting this use case. If people are willing to spend time on that it's their call. > > > 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. Have you even read what the proposed change is? It allows changing the name of the branch that is created by git init using a configuration variable. Nothing else. It is also proposed to change the default for this variable in a future release of git that is expected to have far more disruptive changes, such as different hash used for commit IDs. Thanks Michal
