The behavior of qpush (patch queue reordering)

[Bill Barry]

Benjamin Smedberg wrote:
> I've been thinking about how MQ could allow for a more natural system for
> reordering patches (something better than "edit the series file by hand"),
> and what I thought of was a fairly simple change to the qpush command:
>
> Currently when a user issues `hg qpush patchname`, it behaves just like `hg
> qgoto patchname`, in that it applies all the intermediate patches in the series.
>
> Instead, I think that `hg qpush patchname` should reorder the patch queue so
> that 'patchname' is the next patch in the queue and then push it.
>   
+1

This would solve a use case I'd like to be able to do with the patch 
queue (more easily). I generally don't work on a stack of patches. 
Instead I work on sets of single patches. Unless patches are closely 
related I wouldn't want to work on one on top of another.

Use case:
 >hg qtop
No patches applied
 >hg qpush enhancement_to_blah.patch
at enhancement_to_blah.patch
(do work)
 >hg qrefresh
 >hg qpop
No patches applied
 >hg qpush bugfix_issue_1234.patch
at bugfix_issue_1234.patch
 >hg qapplied
bugfix_issue_1234.patch
...

If I needed to work on a related patch, I could just push it on top. 
Perhaps a switch to qnew and qrefresh could tell the patch that it was 
related to the current top of the stack:

 >hg qapplied
bugfix_issue_1234.patch
 >hg qnew --related -m "something that cannot be started until 1234 is 
finished" enhancement_1234.patch
created new patch
 >cat .hg/patches/enhancement_1234.patch

# HG changeset patch
# User Bill Barry <after.fallout at gmail.com>
# Date 1221168493 15400
# Node ID ad234ed7f2de88f0bee160053886f6ca931bd892
# Parent  ab57069232b4d9ce95e5898d9154410988008ba2
# Requires bugfix_issue_1234.patch
something that cannot be started until 1234 is finished
...


This way if you pushed this patch, it would not get reordered in the 
queue (and the bugfix patch would be applied before it).

Of course qpush -a wouldn't reorder either (maintaining current 
semantics for automated usages). Neither would qpush without any patch name.

I think a --related switch is sufficient to split the order out of the 
series file. The file wouldn't even need to be reordered when patches 
are applied out of order.
> Does this sound like a reasonable proposal? With -m and a saved patch state,
> the command would even be able to merge a patch forward, which would be
> really useful if patches vaguely conflict with eachother.
>   
I'm not certain I understand. Could you explain this part of your 
proposal a little more?

I guess if there was some sort of a qreorder command (pops up a text 
editor and lets you reorder the patch queue, then pops all and applies 
them one by one, bringing up the merge interface when a conflict occurs 
and refreshing each patch as soon as it is applied), it could work.