There is also the older (than histedit) Mercurial Queues (http://mercurial.selenic.com/wiki/MqExtension) which lets users edit history by importing existing revision into the queues, manipulating them and then re-serializing them into regular hg revisions, but it's much more complex to approach (which is probably why Histedit was created).
> It could potentially even do more than that, such as e.g. filtering out data.
Depends on the UI used, git's rebase -i UI (which was reused by hg's histedit) doesn't really work for branch filtering. Branch filtering could also, probably, be a third command of the rewrite extension.
I think Jelmer's suggestion is a good one. In Mercurial, the two concepts are split into two different commands (and extensions, but they could be bundled as a single general-purpose hsitory-rewriting extension) are split into different commands: one is rebase (http:// mercurial. selenic. com/wiki/ RebaseExtension), and the other one is histedit (http:// mercurial. selenic. com/wiki/ HisteditExtensi on).
There is also the older (than histedit) Mercurial Queues (http:// mercurial. selenic. com/wiki/ MqExtension) which lets users edit history by importing existing revision into the queues, manipulating them and then re-serializing them into regular hg revisions, but it's much more complex to approach (which is probably why Histedit was created).
> It could potentially even do more than that, such as e.g. filtering out data.
Depends on the UI used, git's rebase -i UI (which was reused by hg's histedit) doesn't really work for branch filtering. Branch filtering could also, probably, be a third command of the rewrite extension.