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.