What is the simplest way to fix a single broken line in a committed Mercurial changeset?

Question

I frequently run into a use case where I identify a small bug in a committed changeset far after the fact so that reverting the changeset is not an option.

I've looked at similar questions and the Mercurial docs for graft and general advice on backporting changes but either this "simple" use case isn't covered, or it's subsumed in a complex morass of DVCS rebasing/cloning/exporting/importing that is far more abuse than it's worth for what seems to be a trivial operation.

In short, in a repository consisting of

A -> B -> C -> D -> E

there's a one line bug that needs fixing in one file in changeset B which consists of a number of changes to multiple files. Is there a way to do this without reverting/fixing/reapplying all of B? Just being able to do

... -> B -> B' -> C -> ...

would solve this problem.

Note that I have zero context for the concept of rebasing so unless you're willing to spoon-feed it to me, it's not going to help much. My needs are usually pretty simple; I use Mecurial essentially in single-user mode as an advanced form of RCS or SVN, typically using only commit, branch, and merge (absolutely no push, pull, import, export, rebasing, or other 'distributed' features). Yes, I know I'm potentially ruling out a lot of options for solving this problem, but my focus is on fixing my code, not on understanding fine-grained behavior of Mercurial features I never use (sorry, just being honest here.)

If this isn't possible, please let me know so I can just commit my fix as F with the commit message that changesets B through E are broken.

Answer 1

If you've already pushed the change to another user, I would advise you to simply commit as F.

If you haven't, keep in mind the changeset IDs of C, D, ... will all change as well. So the commit hashes will become C', D', ...

I've started to notice that the new 'hg evolve' functionality is very good at what you're asking.

First, a small warning: evolve is (I believe) still experimental right now. Be sure to have a backup! However, evolve really seems like the best fit for this.

First follow the setup instructions.

Then, you can do the following steps:

1. Update to B: hg update -r B
2. Make your change.
3. Commit the amended changeset: hg commit --amend You will now get a warning about unstable changesets (all the changesets that are descendants of B).
4. Run hg evolve --all. This will modify C, D, ... to be correctly based on top of B'.

Answer 2

"Dump" and obvious way:

• hg up B
• Fix
• hg commit
• hg up E
• hg merge (with possible resolving of conflicts)

I.e you commit your fix as child of B (get anonymous branching and additional head - changeset F - in current branch) and merge F into E (as G changeset), which bring F changes into mainline. You can skip update to E: direction of merge in case of anonymous branching doesn't have a much sense

Answer 3

My experience is with git, not mercurial, so I may not be getting the commands quite right. What you're wanting to do is, yes, sometimes termed a "rebase" in DVCS-land, but I come from a different version control, er, vintage, so I don't think of it as "rebase". I just think of it as "rewrite history". It's only a couple of commands.

Spoon-feed, eh? Here comes the plane ...

I think your commands are going to go something like this:

1. enable the rebase extension (seems like it comes with hg but is not enabled?)
2. hg up B
   • to make your fix to B: you'll make it against the code as it was in B
   • hope I have the command right? This should essentially set your working directory to be operating on the source as it was at point B.

3. ... make your fix and commit the changeset on top of B: your tree of changes will look like:

   A -> B -> C -> D -> E  
         \
          -> FIX  <--- you are here
   

   Okay, now comes the rewriting history part. You want to take the history of changes leading up to E, and rewrite them as if they were based on A->B->FIX instead of on A->B.

4. hg up E (because this is the codeline you are interested in rewriting)
5. hg rebase --dest FIX
   • hg is smart enough to know that B is a common ancestor, so it will take subsequent changes and apply them in sequence.

That's it. After this, your history will look like this (as requested):

A -> B -> FIX -> C' -> D' -> E'

I wrote them as C' etc, because it's important to understand that the source at those points will be different than it was before: specifically, they will reflect the incorporation of FIX. The changes made to the code by changesets C, D, E should be the same as those made in C', D', E', unless there is some conflict or other overlap with the fix, in which case you'll probably have to manually interact with the application of the changes.

For example, a refactor of the code affected by the fix could mean making sure the change fix also gets refactored properly. It could even mean another instance of this exercise, if the version control system is unable to track the code between files.

Important, maybe: If someone else has been tracking changes from your repo, and has pulled the original changesets, then by doing this you've taken some of their history away, which might really mess them up, which is why you see people screaming and pulling their online hair out about "rebase".