MQ usability

[Christian Boos]

Dirkjan Ochtman wrote:
> So people invariably complain that MQ is hard to use. On the other
> hand, everyone recognizes that it's also quite powerful.

Actually, it's even rare that I use hg without it, as the patch queue is 
for me a kind of staging area where I prepare and rework my changes 
until they're "good enough" to be frozen.

>  I'd like to fix the former without losing the latter. Therefore, I have a few
> proposals to improve on the current situation:
>
> - remove qgoto, qnext, qprev, qtop: this functionality is already
> covered quite well by qpop, qpush, qseries and log.
>   

I'm not enthusiastic about this part of the proposal,  I use the above 4 
commands all the time and frankly they're quite trivial/automatic to 
learn, so you don't buy much reduction in complexity by removing them.
OTOH I don't use qseries often if at all, as all I want to know is what 
is currently applied or not. So I do 'hg qapp', followed by 'hg qunapp'.

I find the output of "hg qseries -v" to be too verbose: the leading 
patch number is distractive, and the leading A/U key would be better 
replaced by an empty line separating the applied from the unapplied 
patches.
And if I need to know about guards, then I need "qguard -l" anyway to 
see what the guards are (and there, the "unguarded" string could be left 
out for increased clarity, I believe).

> - possibly remove qsave/qrestore as well, since no one seems to use
> them (and many people get confused by them).
>   

These commands are of course a different story - I currently have a 
script for rebasing a patch series using the method from the hgbook 
which is based on qsave [1], but I've never had an use for qrestore, I 
believe. If there's a replacement for the book's rebasing method, then I 
think it's also fine to ditch qsave.

> - make qrefresh <file> not exclude other files from the patch: this
> trips a lot of people up, and the other behavior is often useful, too.
>
> - add a qsplit command to deal with the actual usage of qrefresh for
> excluding hunks (interactive mode for this would rock even more).
>   

Good ideas. Though adding an '--amend' flag to qrecord for reworking the 
current patch would perhaps be a better solution than a new qsplit command.
IIRC, there was also a proposal in the past to integrate qrecord into 
qnew via an '-i/--interactive' flag.
The "qsplit"/"qrecord --amend" idea could then become "qrefresh -i".

> Other possible niceties:
>
> - make qnew vs. qnew -f more intuitive somehow (I'm really not sure
> how, but this usage of -f doesn't really fit in).
>   

Well, this has never disturbed me. On the contrary, more often than not, 
qnew refusing to do anything in presence of local changes was often 
helpful to remind me to either qref the current patch or throw some 
temporary changes away. Giving "-f" to say 'I know what I'm doing, use 
the local changes as a starting point' seems quite fitting to me.

> - make qpush try a merge instead of throwing .rej files around
>   

qpush -m can already do a 3-way merge but you'd have to do some 
(tedious) preparative steps, see [1].

> Any thoughts?
>   

The item with "-f" reminds me of another related discussion: all the MQ 
commands qpush/qpop/qgoto could be made consistent when faced with local 
changes and are given  the '-f' flag, as currently each behaves slightly 
differently. To me that's one of the real difficult aspect of MQ.

One simple idea to improve upon this would be to first stash all the 
local changes in a local_changes.diff file (only if that file doesn't 
already exist of course), and then perform the operation 
(qpush/qpop/qgoto). If the command succeeds, try to apply the 
local_changes.diff again and do a qref if something has been merged 
successfully. If the command fails, inform the user that the local 
changes were saved in that local_changes.diff file. After fixing 
manually the issues with the command, the user can try to apply 
(manually or qimport) the former local changes again.

Bottom line: making MQ behave more consistently and have a few usability 
improvements would be welcome and will have more benefits than removing 
a few convenience commands. Folding the qrecord command into qnew and 
qref via an interactive flag will make it even more powerful. Did I make 
my usual plea for "qup" yet? Ok... not this time ;-)

-- Christian

[1] - 
http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html#sec:mq:merge