Question

I have a repository and am using mq patch queue for unfinished changes. The patch queue is also under version control.

Let’s say I have 2 patches p1 and p2 (applied in that order). Now I make a change on p1:

hg qnew p1
...
hg qnew p2
...
hg qref
hg com --mq -m"(Commit before reject)"
hg qpop p1
{make change}
hg qref
hg qpush -a

… and p2 fails to apply.

The standard way would now be to apply the rejected hunks manually. I
want to use something like MqMergePatch which is nice and uses the merge of
mercurial—but it is based on the deprecated feature:

hg qsave // deprecated: use "hg rebase" instead

My question is: how to do it with hg rebase?

EDIT

After having seen the log of the repository, I do not like at all what MqMergePatch does to it. My main goal in using patches is to have the repository’s history clean, and not scattered with useless details.

Answer 1

The suggestion to use hg rebase is misleading, I think. The MqMergePatch page says it is a modification of MqMerge, which was a technique for rebasing a series of patches on top of new changesets pulled from elsewhere.

However, it involves saving a copy of the patch queue already applied (that’s really all hg qsave does) and using the saved copy as part of the reference for a 3-way merge that effects a patch queue rebase. I used to do that myself before I enabled the rebase extension. Then it was simply a matter of rebasing the first patch on top of the tip changeset I wanted to be its new parent.

That’s not what you want though, because what you want is to basically rebase a patch on top of a patch that you changed. The patch queue is linear, though, and you can only rebase a patch if the changeset onto which it has been applied has other children parallel to the patch queue:

--- A -------- patch1 --- patch2
     \
      \-- B

In the above situation, the patch queue could be rebased on B with hg rebase easily enough (thus the suggestion to use hg rebase), but that has nothing to do with your situation.

An approach to your situation

Here’s an applied patch with unsaved local changes that will conflict with an unapplied patch:

--- A --- patch1           <patch2>
             \
              \-- [changes]

Usually I bite the bullet and handle rejections manually since they are usually few. I find that if I have a situation where there are too many rejections to handle manually, I was probably not organizing them properly in the first place.

If the technique using qsave and qpush -m and so on is preferable to the following to you, it is unlikely that qsave will be removed any time soon, even though it is deprecated.

Here is how I would handle the above situation if I really wanted to take advantage of 3-way merge tools:

(TortoisHg 2.x doesn’t let us rebase patch queues yet, so this is a variant of the finish-rebase-import that I sometimes do.)

• Instead of qrefresh, use qnew to make the unsaved changes a new patch:

  --- A --- patch1 --- patch1b        <patch2>
  

• Finish these patches into regular changesets:

  --- A --- B --- C        <patch2>
  

• Update to the changeset to which patch will apply cleanly (B), and apply the patch:

  --- A --- B --- patch2
             \
              \-- C
  

• Rebase patch2 atop C so that 3-way merge is used to resolve conflicts between local patch2 and other C using base B:

  (I would have to do this in TortoiseHg 2.x by finishing patch2 before rebasing, then importing it back into the queue.)

  --- A --- B --- C --- patch2
  

• Import B and C into the queue as patches again:

  --- A --- patch1 --- patch1b --- patch2
  

• Pop patch2 and patch1b and then fold patch1b into patch1 (renamed as patch1new):

  --- A --- patch1new       <patch2>
  

Now patch2 will apply cleanly to patch1new.