I think the view you present here is outdated. Today, rebasing is used a lot by Mercurial users. Even for the development of Mercurial itself, rebasing is not c

I think the view you present here is outdated. Today, rebasing is used a lot by Mercurial users. Even for the development of Mercurial itself, rebasing is not considered bad, it's considered a requirement for submitting a patch series. That is, the patches are sent by email and applied with 'hg import', and thus implicitly rebased. If that causes too many merge conflicts, you will be asked to rebase it yourself and resubmit it. Mutating history is front and center in the changeset evolution framework people have been working on for some years now. The first step is that Mercurial tracks when it's safe to rebase or edit a commit: each commit has a "phase" which is "draft" initially, but changes to "public" when you push the commit somewhere. The history editing tools ('hg rebase', 'hg histedit', 'hg commit --amend') will then tell you when it's unsafe to edit a commit.