VonC has the answer you’re looking for, the Rebase Extension. It is, however, worth spending a second or two thinking about why neither mq nor rebase are enabled by default in mercurial: because mercurial is all about indelible changesets. When I work in the manner you’re describing, which is nearly daily, here’s the pattern I take:
1. Start working on a new feature:
$ hg clone mainline-repo newfeature-123
do a few commits (M, N, O)
master A---B---C
\
newfeature-123 M---N---O
2. Pull new changes from upstream mainline:
$ hg pull
master A---B---C---D---E---F
\
newfeature-123 M---N---O
3. merge master into my clone so that my new feature
can be developed against the latest upstream changes:
(from newfeature-123)
$ hg merge F
master A---B---C---D---E---F
\ \
newfeature-123 M---N---O---P
and that’s really all that’s necessary. I end up with a newfeature-123 clone I can easily push back to the mainline when I’m happy with it. Most importantly, however, I never changed history. Someone can look at my csets and see what they were originally coded against and how I reacted to changes in the mainline throughout my work. Not everyone thinks that has value, but I’m a firm believer that it’s the job of source control to show us not what we wished had happened, but what actually happened — every deadend and every refactor should leave an indelible trace, and rebasing and other history editing techniques hide that.
Now go pick VonC’s answer while I put my soapbox away. 🙂