Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm on board for removing 'master-slave' terminology from peripherals and replication terminology. I'm on board for removing blacklist/whitelist. But "master" has other meanings besides subjugation. In particular, proficiency or perfection. It was always my sense that git master branch was meant in the same sense as 'gold master' in recording and duplication, or 'master piece' in art and skilled labor.

That said, branches come from trunks, not master or main, and it always felt like a bit of fuckery that git changed the subversion terminology that most of the eventual target audience was already familiar with. Changing to "main" is just confidently incorrect grandstanding. If you're gonna 'fix it' then bloody well fix it.



Git got "master" from closed source SCM Bitkeeper (the Linux kernel team never used Subversion) which did have a concept of "slave" branches as it used master/slave style replication. It's an unfortunate default closer in originating usage to the peripheral and replication terminology than the "pristine copy" terminology.

Changing to "main" is often as much for not breaking a lot of people's muscle memory of "ma<tab>" in the CLI as any other reason to name the default/main branch that. "default" is a good name, too. If you want to use SVN's "trunk" go for it, that's a good name. At this point most git tools don't care what you call it.


I keep going back and forth about whether I should respond to this, so I just upvoted you instead, but now I'm third-guessing myself.

If that's actually the case about BitKeeper then 1) what the fuck, guys, and 2) I'll be thinking hard before I roll out that little rant again. Standing next to a bad actor, you have to gauge your behavior more carefully, because a reasonable response now has additional connotations. Laughing at a joke changes depending on who is telling the joke, for instance.

The part I still feel fairly confident about though is that it feels like someone needs to tap the brakes. It feels like we're on the brink of going too far with this one. And I don't necessarily mean 'witch hunt' style, although that thought has occurred to me more than once. I mean more like diminishing returns and backlash. Maybe we should be wrapping this up and looking for a new problem to fix? Or at least asking the question. Perfect is the enemy of the good, and we haven't really achieved 'good'.


It wasn't the worst mistake that Bitkeeper made in its history. Bitkeeper is going to be an interesting historical footnote for the mistake of dropping the Linux kernel and subsequently prompting the creation of both Mercurial and git.

> Maybe we should be wrapping this up and looking for a new problem to fix?

I feel that we mostly are. It's barely an aside in these release notes and most of the comments are just people still antagonistic to the change, but at this point all the major git repo hosts have made the change for when you init new repos and even new base installs of git itself when you go to git init either have the new default or prompt you (depending on which distro you install, I believe). Like I said, "main" isn't the "perfect choice" but for most of the git tools builders (the major hosts, and git itself) it's good enough and has wide enough support it's "the winner" and has been for several months now. But the tools themselves are happy to let you still use the old default if you don't feel like migrating or personal choices if you don't like the new default. It's all "good enough", and not trying to be perfect.

Renaming branches is mostly just a folder rename, so what harm does it do to just rename the branches? (If it causes some small feeling of harm reduction/justice for those that do object to the old default name, isn't that reason enough?) I'm going to quietly rename branches when I see fit. I'm also not going to force anyone to rename branches if they don't feel like it. That seems to be where most of the tools have landed, no one's forcing the name change, many are suggesting it, but as an action itself it's barely a footnote in Release Notes.

At this point it seems increasingly silly to relitigate why we should stick with the old default instead of just shrugging and moving on to the new one. I don't think your rant was specifically designed to relitigate that, which is why I replied to yours specifically with added context that I thought you might find useful, but some of the other comments in the thread are more questionably about that. The decision has been made: by major corporations listening to their Diversity and Inclusion boards, by the git mailing list itself and even including the developer that chose "master" in the first place without any malicious intent behind it and in general more because of "momentum" than intent, etc. The remaining, recurring complaints seem more about political parties and "anti-virtue signaling" as much as anything technical. (Those same complaints suggest that renaming branches/folders is just "virtue signaling", so complaining about "virtue" as a goal seems it can only be "anti-virtue", right? Our language has gotten so corrupted by social media.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: