On July 13th, we asked the community for your opinion if you would like to change the name of this community.
Results of the Survey :
Yes - 28.1%
No - 71.9% (winner)
Of the 1,201 responses received, we as a community have democratically decided that we should not change the name from PC Master Race. I am grateful to our community for your input, as this was a difficult topic to navigate together.
We'll pin this post for some time and then consider adding a bullet into the sidebar for this Community to help stave off further discussions around this topic as the community has already decided collectively.
This may be an unpopular opinion, but as someone who just started programming like 2 years ago, main makes more sense and is a more approachable name to me than master
Going to change to anything that made sense in git, trunk would have made most sense (or something along those lines). Since your project can have many branches... Tree puns!
But changing it after the product was out was a dumb idea regardless of whatever makes sense and what doesn't. It was blatant pointless virtue signaling that broke some automation and makes a bunch of documentation needlessly confusing (someone just starting out and seeing main but the book they bought to learn says master... Now has to find out why).
The word "Master" isn't exclusively tied to slavery and to deem it offensive on those grounds pretty much guarantees you're American and have an understanding of history that makes any actually educated person want to vomit.
A Master branch, like a master copy of a recording, is the reference copy against which others are measured, it's not a master in the sense of ownership but in the sense of benchmarking, like a master of a craft.
This. And even if it were a matter of control, 'master' is a valid terms for that. It is perfectly fine for one piece of technology to utterly control another. It is not fine to do that with humans.
Cutting out the vocabulary just makes it so that when we run into a real situation, we feel like we can't talk about it.
I will keep vocabulary, and keep history, because that's how we know the reasons for the ways we've changed. Blotting things out of our conceptual vocabulary just makes the next generation susceptible.
This is the main point to me. All the vocab adjustment is so inconsequential over the hope of actual ends to real effects on racism.
I won't try to speak for black people, but I would hope/bet they they'd give white people full license to use the N-word if it meant every cop that ever mistreated someone for their race goes behind bars, no more pay disparity by race, or loan/homebuying mistreatment, and no more wealth gap effects in economic progress.
Yeah talking about virtue signalling is a great way to lose me. My company changed hundreds of repos and it wasn't even a thing, and now they're changed forever.
The concept of a master branch reaches back to CVS (that's Concurrent Version System, not a pharmacy), and Subversion. Makes sense it wouldn't make sense to you. Frankly it doesn't make sense to git at all, but that's a much larger discussion.
The concept of a "master copy" has been around and in widespread use for around a century. It has nothing to do with either software nor social (in)justice. It's just the thing you photocopy so you don't end up making photocopies of photocopies. IMO It should make sense to anyone who, you know, has seen and used paper within their lifespan.
Some terminology, like "master and slave" for IO between devices, did always used to make me really uncomfortable whenever I heard it. But the branch name for software was probably fine.
I have never used Git professionally but I'll tell you the three biggest pain points when working with SVN that I know Git has proper solutions.
No local commits. On the latest SVN versions there is the concept of "shelves" which just basically puts your changes in a separate folder... as of last I checked it was still in Beta but it works decently.
Common code is a pain in SVN. The only way you can do this is using the externals property which has annoyances that seem to be handled better by Git Subtrees.
Commit squashing doesn't exist in SVN. Not a problem for me personally but I've worked with some people that make me really wish I could squash their commits.
Git is really inefficient for large binary files because of the decentralization. SVN for media and Git for text-based files makes sense. Otherwise— I only used SVN briefly, and then fortunately only for media— But yeah, Git is probably better and more useful overall.
Wait, what? When did this even happen (in general)?
Ah, screw this. I'll probably keep "master" in anything that currently has it, and the next time I start something I'll just go back to calling it "trunk" even though I was too young at that point to actually call it trunk, but it makes the most sense for the organization flow.
While convention is not about making sense (does Java class names make any sense?), master makes more sense in this case because main implies that there are secondary that's not related to it. Which really shouldn't happen in any sane repo.
I still use it. When GitHub first forced it on everyone, it broke one or two of my scripts - so I ended up just changing the default back to master out of spite, and haven't touched it since.
It took me all of 5 seconds to fix my automations when GitHub changed that. Also "forced" is a bit strong, they didn't touch existing repos, and it's only the default branch if you let GitHub initialize the repo (which I never do).
It's not just about code, though. I have to write complicated procedures for my job (maintenance of large electrical and mechanical systems, not tech) and I was told I couldn't designate a master procedure. I told that reviewer to pound sand, but if this trend takes hold it will unnecessarily complicate all kinds of work.
I was still a somewhat-clueless high school student at the time, and I had to create new repositories for every assignment in my CS electives. Niche, I know, but someone has to be the edge case...
(They used a dumpster fire home-grown autograder that couldn't handle concepts like "assignment X is in directory Y." Or any sort of file structure that deviated from the IntelliJ project layout. Supposedly they didn't want to pay for a commercial service...)