Hacker News Reader

Comment by samatman | Hacker News Reader

I took the opportunity to rename all my master branches to `trunk`:

https://en.wikipedia.org/wiki/Trunk_(software)

Because y'know, branches? Trunk and branches? It's the older term. I ran into it using Fossil and liked it, now all my git repos have trunks as well.

Of course there's nothing wrong with master, that was just histrionic bullying. At best it was people doing something they can do (change variable names) as a substitute for something they can't (meaningfully affect racial injustice).

But like I said. I took the opportunity. Way better name than main... or master for that matter.

View on HN

Makes sense. I'm not familiar with Fossil, but I know trunk was also the standard when I used SVN back in the day. I think the trunk-branch metaphor makes more sense in the centralized VCS model where there is actually something special about the trunk that makes it distinct from branches, whereas in a DVCS like git master is just another branch except that it happens to be the default one checked out.

Ultimately, it doesn't matter to me in and of itself. Even before last year, it wasn't that unusual to see git/GitHub repos with default branch names other than master (dev is probably the next most common one I've seen), and presumably not because of anything to do with racial justice. "Master" seems most practical to me for the moment, since it's the most standard/common term and is relatively non-overloaded, whereas "main" may be more ambiguous unless expanded to "the main branch" (depending on context).

It almost feels silly to bikeshed about something so minor, but it's not fair for anyone to demand that millions of people change their behavior and/or spend money without meeting some reasonable burden of proof. It's a slippery slope to allowing such unfalsifiable Pascal's-wager-type propositions ("foo may or may not be harmful, so better do bar instead just in case") to be used for more malicious manipulation of markets and geopolitics.

Trunk worked fine for Subversion since it kind of sucked at branching. You generally had to have a reference branch where everything else was understood to be a copy of it.

Modern systems like git don't really work this way. I don't think trunk is properly descriptive anymore because it isn't necessarily the root of all branches. In a GitFlow branching model, commits can move back and forth on feature, bugfix and release branches without ever being merged to develop. On top of that you have branches like gh-pages which should have no shared history at all with other branches.

In keeping with GitFlow, the main development branch on many of my projects is called "develop". I like the name: this is where development happens, where new features are first merged. Unlike "master" or "main" it doesn't imply that it's stable or deployable, and unlike "trunk" it doesn't imply that it's special or that it's the root of all other branches.

> Modern systems like git don't really work this way. I don't think trunk is properly descriptive anymore because it isn't necessarily the root of all branches. In a GitFlow branching model, commits can move back and forth on feature, bugfix and release branches without ever being merged to develop. On top of that you have branches like gh-pages which should have no shared history at all with other branches.

This criticism apply to every other branch naming, especially "master" (it's not a master copy of anything, then). Maybe "main" would be the best one since it highlights the most important branch of that git tree.

Most of the Git projects I've worked with followed the "trunk" model of there being one core branch; in theory, you can use git in other ways but in practice that's the main one. That said, trunk works, but so does main, production, or even development depending on whether you want to communicate that the mainline branch is considered stable or unstable.

Sure, and this is one of the nice things about git, that it supports a number of flexible workflows.

My repos are in fact trunk and branch shaped: the trunk branch is always the first commit, and I tend to just have feature branches. That won't last forever, I'll need to start having release branches and the like, but 'trunk as root' with the first commit is going to be a constant.

So 'develop' is a fine choice. I worked at a company which had a 'master' branch but really only used it for releases. It wasn't a continuous deployment model, so everything would land on 'develop', turn into a candidate branch near release time, and then land once on master when it was blessed for release.

So master was just a series of squashed deltas between point releases, which kind of matches the semantics of 'master' if you squint: like it was the gold master from which release copies (including one client who took delivery by CD-R!) was pressed.

Then you should stop using Fossil.

It gives a bad example for climate change.

Reply on news.ycombinator.com