Rewriting public branch history is not generally used by any major project except in extreme circumstances. This reads like an attempt at satire by someone who doesn't understand the actual utility of history rewriting in git, which is generally for extending version control to your development changes (e.g. what is more formally codified in Mercurial as the draft phase).
Re-read the post. At no point did the author claim he rewrote public history. He had a certain changeset in the experimental branch, an assumed private branch. He then broke that changeset into two, merged the ready-for-production code into the stable branch and then rewrote history of the experimental branch so that it sat on top of the updated stable branch. As simple as that.
In fact, I'm one "hop" away from public. Upstream from me is a staging repo, and public is the one upstream from that. The staging repo is needed so I can bounce changes among platforms. Its branches get rewritten regularly.
All history editing in Mercurial needs to be enabled via extensions (so that you don't shoot yourself in the foot by accident). That said, the term extension is a bit of a misnomer in this context, since most "extensions" that are being used for this are parts of core Mercurial and are simply enabled by an option (the one prominent exception I can think of is "evolve", since it's unfinished).
Here's how you do it:
hg histedit -r .
# change "pick" to "edit" in the edit plan.
hg commit -i
hg commit
hg histedit --continue
Alternatively, and preferred, because you can then test intermediate commits:
hg histedit -r .
hg shelve -i
# test that it works
hg commit
hg unshelve
hg commit
hg histedit --continue
If you don't want to affect the files in your current checkout, use hg share to create a separate checkout.
That splits the commit in two; use hg graft or hg rebase to move the commits to different branches.
> Its always a huge pain point.
Not sure why; Mercurial's commands for history editing are conceptually pretty similar to Git's. I suspect that it's mostly a difference in familiarity with the tools.
I'm sure part of it is familiarity, but also a difference in documentation. Git's documentation makes it EXPLICITLY clear that one thing Git is intended to be awesome at is easy branching and merging, and rebasing. When I worked on a Mercurial codebase, we pretty much didn't do feature branches (or the hg equivalent), and therefore "rewrite history" was considered not just heresy, but likely to Break Everything.
It's not that it's impossible, but that it was not clearly described how to do it right, in contrast to the Git documentation. Now that I've been using Git for nearly three years, and have used it to save my bacon, I'm sure I could find some way to do similar with Mercurial ... but only after having learned it with git.
Even public history can be rewritten, and it's not too bad to deal with. For several months, earlier this year, I was battling some tough bugs in a kernel USB driver, along with a few other developers. I set up a "wild repository" (not an official repository, but one for experimental changes---though public in the sense of being shared). I rewrote the testing branch regularly. I even adopted a scheme, whereby I would rename a branch through the names "name.1" and "name.2" (deleting the old name.2), similarly to rotating logs. I'd send out a "heads up" e-mail whenever I did this.
A rewritten branch isn't hard to pick up. Git tells you that the history has diverged (N commits here, M over there). If none of the local history is yours, you can just throw it away with a "git reset --hard <origin>/<branch>". Or else you can rebase those changes which are yours.
It's only bad to rewrite "really public" branches that are distributed to the world. Even then, it can be okay to clean up some oops: like seconds after pushing a release, some last minute change needs to be made (typo in the release notes file or whatever).
