Hg: How to do a rebase like git's rebase

Question

In Git I can do this:

1. Start working on new feature:
$ git co -b newfeature-123  # (a local feature development branch)
do a few commits (M, N, O)

master A---B         


        

Answer 1

Since some people have chimed in saying they think it's good to keep every iteration of everything, I'll point out that for larger open-source projects, accepting changes full of merges and development iteration would make for a messy mainline revision history, and make the revision history less useful for seeing how the current version got there.

This works well when submitted changes are reviewed by people that didn't write them, before they're accepted, so changes that do go into the mainline are generally debugged and working. Then when you backtrack to the origin of a line, you see all the changes that go with it, not some point in the middle of development of the change it's part of.

The x265 contributors page explains how to re-commit a set of changes you're working on, to get them ready for submission to the x265 project. (Including use of TortoiseHG to commit some but not all changes in an individual file, like git gui's stage/unstage diff hunk for commit).

The process is to get hg updated to the upstream tip, and then get all your changes uncommitted in the working directory. Shelve any that aren't part of what you want to submit, then break the rest into as many separate commits are appropriate, with nice commit messages.

I guess you'd copy/paste and then edit commit messages from previous iterations of a patchset that you're revising. Or maybe you could graft your old commits (cherry-pick in git language), and then amend them one by one, to get your old commit messages as a start point for editting.