Re: Rename offensive terminology (master)

From: Whinis <whinis@whinis.com>
Date: Jun 16, 2020, 16:09 UTC
Message-ID: <0f54e6e6-c09f-9894-ea06-812cc4f7e88b@whinis.com>
In-Reply-To: <20200616154942.z75uo34wsbcvphe5@chatter.i7.local>

On 6/16/2020 11:49 AM, Konstantin Ryabitsev wrote:

Show 15 quoted lines

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

This makes me highly confused because just one email earlier said to leave them off this list and now you are saying in one line their opinion weighs as much as everyone else and then say they are a larger user so if they ask it should happen. You have quickly jumped from their opinion shouldn't matter to its equal to their opinion is apparently worth more because they are a large user.

So which is it? Should they be left off the list or is the mere fact they are changing something enough to ignore what this could break?

Show 17 quoted lines

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

A single project not conforming is different than changing the default and forcing all documentation to be updated. Not to mention this very well could cause a split in the community itself leading to even more issue. print in python is a poor example as it had obvious technical merit to remove items that did not match other paradigms in the language. Also the Linux Kernel ABI is extremely well documented and even items from 10 years or even 20 years ago conform to it. My argument is not documentation alone should never be updated its that this is a fundamental change invaliding essentially all current available resources. A change this large should require just as large a reason to implement.

Show 7 quoted lines

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

So the effect of changes to how the default install works on users is out of scope? What exactly is in scope then because other services were out of scope earlier but now are apparently an important input. I would say how this change affects the majority of users is very much the exact reason this should not happen.

Show 5 quoted lines

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

Kinda disagrees with the definition of default doesn't it if your fix is to tell everyone using current tools to change the default back to what it was so it continues to work? Its nearly impossible to estimate how many things were coded by different interns and are now technical debt and would need to be changed either in all future deployments defeating the point of a default or require significant work to rework.

Asking all users to change their methods going forward or rework all their technical debt are both extremely unfair to users.

Show 16 quoted lines

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

1. If they are already renaming their branches then they have no issues

2. if there is bugs that needs to be fixed but no where have I seen 
examples where this breaks and need I remind you the title of the list 
is "Rename offensive terminology (master)" which is not saying things 
are broken but that things must change due to offense.

What is an example of Git not working with arbitrary branch names? What fix does changing the primary branch name fix if the issue is with arbitrary branch names?

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

Then consider me that person.

Show 5 quoted lines

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

You yourself have admitted its already possible to have an arbitrary collection of branches, so what does this change?