"I cannot understand why so many people are resisting this change."
Because it is a breaking change for no real reason - and as an engineer it makes my eyes roll.
It is also a "panic reaction" and a "displacement activity" instead of facing the real problem - and as and intelligent person who dislikes BS, especially instead of real solutions and actual debates on how to reach them, it makes me cringe.
And it's also done in an idiotic way - which again, makes me as an engineer and an intelligent person sigh in annoyance.
Let's start with the very first thing: Git's (and thus: Github's) "master" has nothing to do with slavery. There are no "slaves" in Git. The "master" refers to the "master recording".
I know that there is this one email where SOMEONE ARGUES that the naming PROBABLY comes from BitKeeper where it was used as part of the master/slave terminology. And I see you have also used it in this thread as if it were some kind of evidence.
Nope, it's not. It's someone's theory, and I find it alarming how people driven by their agenda try to push an OPINION AND THEORY as an evidence.
Especially when it's totally false: twitter.com/xpasky/status/12722807...
This makes it the whole premise false - thus my claim that this change is for "no real reason".
On the other hand, tt's a breaking change, which means extra cost (for no reason) for developers using GitHub, for developers who will start using GitHub in the future and also for GitHub's own tech department.
1.) It breaks the common standard shared by Git, GitHub and GitLab. This hurts portability and adds annoyance. Now it will e.g. be possible that I will get different result if I first create a local git repo and then upload to GitHub compared to if I did it the other way around.
2.) It breaks tooling.
Do you have a release script that makes sure that you are on the latest version of the master branch before allowing the release? You have a problem then.
Do you have a pre-commit hook that guards against committing directly to the master? You have a problem then.
Do you have any kind of innovative / crazy / highly customized / whatever tooling that references the master branch in anyway? You know, all the kind of unforeseeable stuff that is sure to happen a lot when over 40million developers are using your stuff for all kinds of projects.
Yepp, you will have a problem.
Now, of course GitHub will try to mitigate these problems with the addition of new tooling and automation - which will probably add new layers of indirection for the users and new functionalities to maintain (and thus quite possibly new bugs) to the GitHub team.
And normally, such a change would be rolled out in steps to test waters and stuff. You know stuff like beta testing as such. But now, instead it is rolled out in one huge update which will affect all the over 40M developers. Heck of a way to test new - and seemingly put together in a rush - features.
3.) It breaks documentations and TUTORIALS. And most of these will not be updated. Now we will have broken tutorials all over the net. So new users will be easily confused.
Add the possibly user indirection that the new GitHub automation will possibly introduce and you have just effectively increased the entry bar for using GitHub for new devs.
And now let's continue about how this is a "displacement activity" instead of trying to make a real solution.
I have no problem replacing the master-slave terminology. But the intelligent and engineering way is to do this by acknowledging the cost of doing this and trying to minimize it.
From a purely technical point of view, the master-slave terminology is a very good terminology. It clearly express the relation of the master and slaves. The words themselves are not that much used outside the terminology (the "master" is a bit more, but the "slave" is basically only used in this context which makes reasoning about and searching the code much easier). They are widely used in the industry, so everyone knows what they mean.
So if we are to replace this terminology, then as an engineer, my requirements is to have a similarly good new terminology for as low a cost as possible.
This means that first of all, there should be a wide-spread discussion about what should be the new terminology. Let's create a new widely used replacement instead of everybody choosing their new one.
Secondly, I want the new terminology to be expressive. Also want the new words to be not overused by other meanings.
Renaming the master to main does not satisfy these requirements.
The "main" is already used for a lot of stuff. And whatever you rename the "slave", it won't express the same relation. So it's simply a quite bad name.
Thirdly, I want the cost of change to be minimized. So that the amount of code, documentation, tutorial, whatever that needs to be updated is minimized.
The obvious way to achieve this is to leave the name "master" and rename "slave".
E.g. rename "slave" to "minion" as it is done in SaltStack.
It clearly express the intent, the name "minion" is highly unlikely to to be used in some other way in the code and it minimizes the cost by keeping the name "master".
Oh look, if we don't do BS as a panic reaction we could actually do some meaningful stuff!
And that's why this is infuriating.
GitHub could have just say, that:
"our 'master' branch refers to the 'master recording' and we do not use master/slave terminology anywhere so it does not affect us, but we still feel that inclusive language is a positive goal and we should push for that. But since the term is a wide-spread industry standard, it should also be replaced by a wide-spread new standard instead of everyone just trying to figure out their own replacement in a rush.
So we are calling upon the big companies and open source community to let's find a new terminology that will be adapted.
The new terminology should clearly express the intention behind the architecture (i.e. one boss delegates the jobs to others while supervising them); It should be not over-used for other uses; And ideally, the change should be as natural and pain free as possible.
For this reason, our team has checked the alternatives that are already in use and found the following ones to be a good candidate:
master / minions:
...
"
Look at the difference. This reaction would have made sense. This reaction would have actually tackled the actual problem. On a industry level, nonetheless.
This reaction would have actually also taken into consideration the millions of engineers who uses GitHub.
Many of them not even being from the US so they don't even have these kind of "triggers" that you have in the US. What happens here is basically a US-centered panic reaction being forced down the throat of the whole world.
I don't know if there is already a "US progressive" world for this, but shouldn't we call this something like "cultural dictatorship"?
I'm a black software engineer and I don't find the use of the word "master" offensive, in any way whatsoever, and neither do any of my black developer friends.
In my opinion, it's an unnecessary change that doesn't make blacks in the tech industry any better. I heavily doubt that there was once a black dev that quit programming just because he/she ran into GitHub's "master" term.
I also doubt if there can even be any measurable impact aside from the PR and social points GitHub is getting by implementing this change.
Same here. I'm Brown, and I think this kind of fetish that these so-called SJWs have with derogatory terms like "Person of Color" (what, do White people not have any colour?) as well as segregating the world into "Whites" vs "non-Whites" (never mind that the "non-Whites" part consists of Asians, Blacks, Hispanics, Native Americans, Indians, Pakistanis, Bangladeshis. Turks, Australian Aboriginals and so) is honestly dehumanising. Shameful and reprehensible. I'd rather have to deal with an outright racist than with these closet racists.
Because it is a breaking change for no real reason - and as an engineer it makes my eyes roll.
It is also a "panic reaction" and a "displacement activity" instead of facing the real problem - and as and intelligent person who dislikes BS, especially instead of real solutions and actual debates on how to reach them, it makes me cringe.
And it's also done in an idiotic way - which again, makes me as an engineer and an intelligent person sigh in annoyance.
Let's start with the very first thing: Git's (and thus: Github's) "master" has nothing to do with slavery. There are no "slaves" in Git. The "master" refers to the "master recording".
I know that there is this one email where SOMEONE ARGUES that the naming PROBABLY comes from BitKeeper where it was used as part of the master/slave terminology. And I see you have also used it in this thread as if it were some kind of evidence.
Nope, it's not. It's someone's theory, and I find it alarming how people driven by their agenda try to push an OPINION AND THEORY as an evidence.
Especially when it's totally false: twitter.com/xpasky/status/12722807...
This makes it the whole premise false - thus my claim that this change is for "no real reason".
On the other hand, tt's a breaking change, which means extra cost (for no reason) for developers using GitHub, for developers who will start using GitHub in the future and also for GitHub's own tech department.
1.) It breaks the common standard shared by Git, GitHub and GitLab. This hurts portability and adds annoyance. Now it will e.g. be possible that I will get different result if I first create a local git repo and then upload to GitHub compared to if I did it the other way around.
2.) It breaks tooling.
Do you have a release script that makes sure that you are on the latest version of the master branch before allowing the release? You have a problem then.
Do you have a pre-commit hook that guards against committing directly to the master? You have a problem then.
Do you have any kind of innovative / crazy / highly customized / whatever tooling that references the master branch in anyway? You know, all the kind of unforeseeable stuff that is sure to happen a lot when over 40million developers are using your stuff for all kinds of projects.
Yepp, you will have a problem.
Now, of course GitHub will try to mitigate these problems with the addition of new tooling and automation - which will probably add new layers of indirection for the users and new functionalities to maintain (and thus quite possibly new bugs) to the GitHub team.
And normally, such a change would be rolled out in steps to test waters and stuff. You know stuff like beta testing as such. But now, instead it is rolled out in one huge update which will affect all the over 40M developers. Heck of a way to test new - and seemingly put together in a rush - features.
3.) It breaks documentations and TUTORIALS. And most of these will not be updated. Now we will have broken tutorials all over the net. So new users will be easily confused.
Add the possibly user indirection that the new GitHub automation will possibly introduce and you have just effectively increased the entry bar for using GitHub for new devs.
And now let's continue about how this is a "displacement activity" instead of trying to make a real solution.
I have no problem replacing the master-slave terminology. But the intelligent and engineering way is to do this by acknowledging the cost of doing this and trying to minimize it.
From a purely technical point of view, the master-slave terminology is a very good terminology. It clearly express the relation of the master and slaves. The words themselves are not that much used outside the terminology (the "master" is a bit more, but the "slave" is basically only used in this context which makes reasoning about and searching the code much easier). They are widely used in the industry, so everyone knows what they mean.
So if we are to replace this terminology, then as an engineer, my requirements is to have a similarly good new terminology for as low a cost as possible.
This means that first of all, there should be a wide-spread discussion about what should be the new terminology. Let's create a new widely used replacement instead of everybody choosing their new one.
Secondly, I want the new terminology to be expressive. Also want the new words to be not overused by other meanings.
Renaming the master to main does not satisfy these requirements.
The "main" is already used for a lot of stuff. And whatever you rename the "slave", it won't express the same relation. So it's simply a quite bad name.
Thirdly, I want the cost of change to be minimized. So that the amount of code, documentation, tutorial, whatever that needs to be updated is minimized.
The obvious way to achieve this is to leave the name "master" and rename "slave".
E.g. rename "slave" to "minion" as it is done in SaltStack.
It clearly express the intent, the name "minion" is highly unlikely to to be used in some other way in the code and it minimizes the cost by keeping the name "master".
Oh look, if we don't do BS as a panic reaction we could actually do some meaningful stuff!
And that's why this is infuriating.
GitHub could have just say, that:
"our 'master' branch refers to the 'master recording' and we do not use master/slave terminology anywhere so it does not affect us, but we still feel that inclusive language is a positive goal and we should push for that. But since the term is a wide-spread industry standard, it should also be replaced by a wide-spread new standard instead of everyone just trying to figure out their own replacement in a rush.
So we are calling upon the big companies and open source community to let's find a new terminology that will be adapted.
The new terminology should clearly express the intention behind the architecture (i.e. one boss delegates the jobs to others while supervising them); It should be not over-used for other uses; And ideally, the change should be as natural and pain free as possible.
For this reason, our team has checked the alternatives that are already in use and found the following ones to be a good candidate:
Look at the difference. This reaction would have made sense. This reaction would have actually tackled the actual problem. On a industry level, nonetheless.
This reaction would have actually also taken into consideration the millions of engineers who uses GitHub.
Many of them not even being from the US so they don't even have these kind of "triggers" that you have in the US. What happens here is basically a US-centered panic reaction being forced down the throat of the whole world.
I don't know if there is already a "US progressive" world for this, but shouldn't we call this something like "cultural dictatorship"?
Just food for thoughts...
This really hits the nail on the head.
I'm a black software engineer and I don't find the use of the word "master" offensive, in any way whatsoever, and neither do any of my black developer friends.
In my opinion, it's an unnecessary change that doesn't make blacks in the tech industry any better. I heavily doubt that there was once a black dev that quit programming just because he/she ran into GitHub's "master" term.
I also doubt if there can even be any measurable impact aside from the PR and social points GitHub is getting by implementing this change.
I totally agree. Like honestly, I saw this post the other day and
started questioning whether I'm black because I didn't see it this way.
Same here. I'm Brown, and I think this kind of fetish that these so-called SJWs have with derogatory terms like "Person of Color" (what, do White people not have any colour?) as well as segregating the world into "Whites" vs "non-Whites" (never mind that the "non-Whites" part consists of Asians, Blacks, Hispanics, Native Americans, Indians, Pakistanis, Bangladeshis. Turks, Australian Aboriginals and so) is honestly dehumanising. Shameful and reprehensible. I'd rather have to deal with an outright racist than with these closet racists.
Well said!