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
