What Is So Wrong With Mercurial's Named Branches?

I just installed the very latest version of mercurial, 2.0.2. It added a new little feature that warns you when you create a branch. Huh? This is what it looks like:

$ hg branch foo
marked working directory as branch foo
(branches are permanent and global, did you want a bookmark?)

Really? Have we let the git advocates push us this far? Do we really need to start discouraging named branches?

I googled around to see if I could find where the self-hate for mercurial's named branches is coming from and I found things like this, "it is almost never a good idea to use this facility for short-term branching, since branches created this way are inherently 'eternal'." (those quotes around eternal are good, actually, but you didn't explain why they should be there), and this, "you can never really delete branches (since that would mean altering older commits)." (editing history, oh noes!), and others like this. And these were all written by apparent mercurial supporters! I understand when a git developer writes misinformation about mercurial and uses it to try and make git look better (that's only human), but we mercurial users should know not to listen to it!

Here's what I think is going wrong. Git users love flexibility. The love it so much that they even include modifying their local repository history right into their standard workflow. git rebase is a core command. From what I can gather, even though mercurial now (as of years ago, actually) has powerful rebase and patch queue extensions, mercurial users still get the heebie-jeebies when they think about modifying repository history. This is where the git envy comes from. You see, git useres can alter their branch names, or even delete branch names without using scary rebase. Fact is, though, git could adopt mercurial-style named branches and git users would rebase them away or rename them with rebase willy-nilly just like they do with everything else that they deem needs editing in their history. The fact that git users can rename or delete their branches without using rebase is almost completely incidental. If you allow the use of rebase or patch queues, mercurial named branches are not any more permanent than any other changeset in the repository history. Mercurial bookmarks allow mercurial users flexibility around branch names without needing to resort to scary history editing extensions, and that makes us happy, but I don't think that we should talk down mercurial named branches. There are times when you want the branch name associated with a commit to be just as "permanent" as the commit is. Let us do that without dumb warnings that make named branches sound like a bad idea.

The only other argument people may have against mercurial's named branches is the possibility of name collisions. As if that's something that's really hard to deal with. Anyone who has written a fair amount of C code (I'm looking at you, git developers) knows how to prefix a name to get poor-man's namespaces. Alternatively, many projects require an issue tracker number in a feature-branch or bugfix-branch name. Name collision problem solved.

In conclusion, mercurial named branches are fine. Use them more. Use rebase and/or patch queues[1] to rename or delete the branches when necessary. If that really bothers you, you have bookmarks now, but don't go all git-apologetic on named branches. Mercurial is every bit as awesome as git.

1. Before you push to a publicly accesible repository, of course. Ask a git user why that's important.

Comments

Alex V Koval said…
yah, that confuses me. mercurial named branches fit our workflow the best way, because we want to stay our branch history forever.
June 4, 2012 at 1:35 AM
Anonymous said…
The mutable-branches extension (http://mercurial.selenic.com/wiki/MutableBranches) can give the illusion of having renamed a branch.
December 11, 2012 at 2:02 AM
shelby said…
Face it, you are an idiot, just like Linus Torvald said.

> The fact that git users can rename or delete their branches without using rebase is almost completely incidental.

Named branches can't be assuredly deleted because they have infected the changesets of every unknown decentralized copy in existence on earth. Don't make your changesets public then. Then you don't need DVCS, just use CVS.

> knows how to prefix a name to get poor-man's namespaces

Each Git repository’s set of local branch names can have its own namespace because lightweight branch names are not immutably recorded in changesets. Thus each repository can refer to another repository’s set of local branch names by prepending what ever name the referring repository chooses for the other repository. Whereas, Mercurial’s bookmarks (as currently implemented) invert the naming unique responsibility from the referrer to the referent; and thus require each repository to select a name which will be unique from all other possible names that any other repositories might use. A repository self-prepending its own name to its branch names is only a solution if every repository’s name is globally unique.
November 26, 2015 at 8:25 PM
Bryan said…
Linus commented about me personally? That would be an exciting first for me. Do you have a link to that?

You are correct that if you push a mercurial branch it can't be renamed (and I mentioned that in my footnote), just like you can't do any other editing of commits (amending, rebasing, folding, etc.) once you push them.

Generally the way things work is you pull in changes from the repo you are about to push to and make sure your push isn't going to break anything before you push to it. When you pull you might discover that you picked a bad name for your branch (one that was already taken, for example) and then you could rename it using rebase. You could also create a named branch to keep track of your local work, pull, then rebase your changes onto another branch forever deleting the named branch you used when doing your local development. My point still stands: even with named branches, you have options.

I'll admit I haven't used mercurial bookmarks much, but from the documentation:

https://www.mercurial-scm.org/wiki/Bookmarks

it sounds like you are correct, there is no automatic namespacing done like with git. Honestly, I found git's auto renaming of branches confusing at first, but I can see how for a large project with many many people involved (like the linux kernel) auto namespacing would avoid another sort of confusion.
December 3, 2015 at 9:05 AM
Post a Comment

Popular posts from this blog

SystemVerilog Fork Disable "Gotchas"

This is a long post with a lot of SystemVerilog code. The purpose of this entry is to hopefully save you from beating your head against the wall trying to figure out some of the subtleties of SystemVerilog processes (basically, threads). Subtleties like these are commonly referred to in the industry as "Gotchas" which makes them sound so playful and fun, but they really aren't either. I encourage you to run these examples with your simulator (if you have access to one) so that a) you can see the results first hand and better internalize what's going on, and b) you can tell me in the comments if this code works fine for you and I'll know I should go complain to my simulator vendor. OK, I'll start with a warm-up that everyone who writes any Verilog or SystemVerilog at all should be aware of, tasks are static by default. If you do this: module top; task do_stuff ( int wait_time); #wait_time $display ( "waited %0d, then did stuff" , wa...
Read more

'git revert' Is Not Equivalent To 'svn revert'

I just learned that if you have some changes in your working tree that you want to get rid of, you don't type 'git revert' like you might guess. No, that's what cvs, subversion, mercurial, and bazaar (to name a few) use revert to mean, but not git. With git, revert is used to undo actual commits. Thankfully, you can undo your revert with another 'git revert', I just learned. So let me repeat to be clear, if you have changes to your working files that you want to abandon, DO NOT do this: git revert HEAD That will undo your last commit. Do this instead: git reset --hard HEAD I'm glad I have that straightened out now. I'm wondering if /etc was really a good place for me to start out playing with git. UPDATE: Nearly two years later and I'm still getting comments on this. I'm glad I've been able to help people out this way. The discussion in the comments is good, and one thing I'd like to point out is that I now always use...
Read more

SystemVerilog Streaming Operator: Knowing Right from Left

SystemVerilog has this cool feature that is very handy for converting one type of collection of bits into another type of collection of bits.  It's the streaming operator.  Or the streaming concatenation operator.  Or maybe it's the concatenation of streaming expressions (it's also called pack/unpack parenthetically).  Whatever you want to call it, it's nice.  If you have an array of bytes and you want to turn it into an int, or an array of ints that you want to turn into an array of bytes, or if you have a class instance that you want to turn into a stream of bits, then streaming is amazing.  What used to require a mess of nested for-loops can now be done with a concise single line of code. As nice as it is, getting the hang of the streaming operator is tough.  The SystemVerilog 1800-2012 LRM isn't totally clear (at least to me) on the details of how they work.  The statement from the LRM that really got me was this, "The stream_operator <...
Read more