Re: Rename offensive terminology (master)

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Tue, Jun 16, 2020 at 09:55:29AM -0400, John Turner wrote:
> 
> > 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.

Github is an equal partner in this conversation and their opinions weigh 
about as much as anyone else's. However, they are certainly one of the 
larger users of Git, so if they ask to make it possible to change the 
default branch name without any negative effects on how Git works, this 
is a valid request and a valid discussion.

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

It doesn't work perfectly. The goal is to improve it so it does.

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

This is true for all technical documentation, though. 10 years ago I 
could reasonably expect "print foo" to work in Python, but now it will 
return an error. Most documentation written for the Linux kernel is 
woefully outdated a few years after its publication.

Documentation has never prevented projects from implementing changes 
that would require docs to be updated.

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

As this change would be made by individual repository maintainers, this 
is out of scope of this discussion. None of the changes being discussed 
would in any way force existing repositories to rename their branches.

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

"Entirely retool" is not a fair statement for "set a single config value 
in a single file".

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

You can't avoid the following facts:

1. Projects are already renaming their branches to whatever they want
2. There are parts of git where this breaks internal logic
3. We should fix internal logic so it doesn't break

The fact that Git doesn't 100% work with arbitrary branch names is a bug 
that needs to be fixed. Introducing a config variable that designates 
the primary branch name is the way to fix it.

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

Nobody is preventing you from being that person.

> I leave with this, if we are to leave out the emotions what good 
> reason is there to push through this change?

Most software development is reactive to emergent situations. In my 
view, making it possible for someone to have an arbitrary collection of 
branches in their repository is reason enough to push this change.

-K