[glitchdout]

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.

[kazinator]

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.

[rbehrends]

Which you can do in Mercurial, Bazaar, or Darcs, too. It's not really something Git-specific.

[shadowmint]

Ive never managed to do this in mercurial. Its always a huge pain point.

Is there some extension that helps?

[rbehrends]

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.

[gknoy]

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.

[sampo]

> Ive never managed to do this in mercurial.

`hg record` might be somewhat more cumbersome than `git add -p`. But `hg rebase` should about as nice as `git rebase`?

[krupan]

hg crecord is awesome for fine grained patch splitting.

[kazinator]

> Its always a huge pain point.

And that is a nonstarter, once Git has opened your eyes to light-weight rewriting, done casually and frequently.

[nephyrin]

I think I was Poe's Law'd by his last paragraph