Mercurial branch or rebase?

Question

After using mercurial daily for over a year, we are about to find a better workflow for our DVCS. Inspired by a successful Git branching model we are about to move away from our "push daily work into master repo and fork off release branches at regular intervals" workflow into "work on separate feature branches and merge finished features back into master".

Anyway, the problem I have had with branching and mergeing in mercurial (branch using clone) is the actual merge process. I have no problem with merges generating additional changesets, the problem I have is that it usually generates huge changesets that contains more changes than the original changeset+merges, The merge changeset also contains changesets from other heads as well.

So I have recently realised that when we do pull from master repo,then update/merge and finally push, we create these unnecesary large changesets.

What we should do is rebase instead of pull, update/merge.

Now rebase was originally an extension to mercurial, it is still an extension but is nowadays shipped together with the mercurial distribution.

When following other threads, especially those comparing git with mercurial, it seems like one of the largest difference between the two is the fact that git does not support branches, but has native support for rebase. Mercurial has no native suppport for rebase but support branches.

So my question then, if we should adopt to a more flexible workflow using feature branches, we must have a solid branch/merge workflow that does not cause havoc in the master branch. The master branch should be peach containing only changesets containing a single feature without any extra changesets for any merge operations carried out. Now can that be done in mercurial without rebase support?

As a separate issue, I would like some input on how to aggregate multiple changesets in a feature branch into one single changeset when pushing into the main branch.

I have read A Guide to Branching in Mercurial but it never mentions the pros or cons regarding ease of mergeing, or more specifically, how the results of the merge is commited into the master branch.

• Neil Butterworth: What makes you think git does not support branches?
• Ernelli: I am not very familiar with git, I've used it extremely little (A few github pushes), so maybe it supports branches. My deduction came from reading "Why I Like Mercurial More Than Git" linked to above where he whines about git lacking the "family" convention, which in mercurial represents the branch.
• John Lyon: This is a good primer on git branching. It's easy! /end_derail
• Kevin: Essentially, Git branches are like Mercurial bookmarks. There are some minor differences, of course. Git does not have anything like Mercurial's named branches.

Answer 1

Have you considered to use named branches for your feature branches? This way you can develop a feature by committing to it as often as you want, while the master branch is not polluted by these commits. When a feature is ready you merge the corresponding feature branch into your master branch. This will produce a merge changeset which only contains the difference between the feature branch and the master branch. When we started to use Mercuial we also used a workflow where we separated feature development solely by separate clones. However, since we use name branches life got much easier for us. The changesets are cleanly separated and you can have all branches within one repository without getting confused. Furthermore, you can switch between different branches easily. And as I said, you get a much cleaner history.

• Nicol Bolas: +1: I have seen far too many online resources promoting the "clone to branch" methadology. Mercurial has excellent support for in-repo branches; it's a shame that so many choose not to use it.
• dragan.stepanovic: From my personal experience, if you have 1000 users and 150 named branches in one repo it gets reaaaally difficult not to make a mistake and commit to the wrong named branch.