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
