> I'm excited because it is SO MUCH more powerful than git's commit history rewriting, because "I re-wrote history" becomes part of your (distributed) repository's history.
That can be a feature or a bug.
This would be wildly useful for a public branch that needs periodic rebasing, because unlike a git rebased branch, you'd have a history of the rewrites.
On the other hand, most users who locally use git rebase -i to transform a local series of WIP patches into a sensible patch series for submission do not want any record of the intermediate commits (which may not bisect, or even build, and which may have commit messages like "WIP: try fixing it again"). git makes it easy and sensible to commit early and often, and then sort out a sensible patch series from the result.
This is of course a straw man as Mercurial already has several tools for this (MQ, rebase, histedit), which will keep working as-is even with changeset evolution. So changeset evolution allows things in addition to the local rebasing.
Not only that, but outdated changes aren't shared by clone or pull unless you explicitly ask for them. The full history stays on the server but intermediate commits slowly fade away as users hardly ever pull them.
That can be a feature or a bug.
This would be wildly useful for a public branch that needs periodic rebasing, because unlike a git rebased branch, you'd have a history of the rewrites.
On the other hand, most users who locally use git rebase -i to transform a local series of WIP patches into a sensible patch series for submission do not want any record of the intermediate commits (which may not bisect, or even build, and which may have commit messages like "WIP: try fixing it again"). git makes it easy and sensible to commit early and often, and then sort out a sensible patch series from the result.