MQ usability

[Peter Williams]

On 11/08/09 02:25, 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. 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.
>
> - possibly remove qsave/qrestore as well, since no one seems to use
> them (and many people get confused by them).

qsave and its usefulness in updating ones patches when the underlying 
code changes (see page 197 of "Mercurial, The Definitive Guide", 
ISBN-978-0-596-80067-3) is the MQ feature that most distinguishes from 
other patch management systems (such as the very popular "quilt" 
<http://savannah.nongnu.org/projects/quilt>).  So it would be a big 
mistake to remove it.

It's what got me to switch from git/quilt to hg/mq (even though this 
involved converting a large git repository to hg and keeping it up to 
date) when I was maintaining the PlugSched patches to the Linux kernel.

>
> - 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.

Then what would be the point of having the <file> argument if qrefresh 
behaves the same with it as without it.

>
> - add a qsplit command to deal with the actual usage of qrefresh for
> excluding hunks (interactive mode for this would rock even more).
>
> 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).
>
> - make qpush try a merge instead of throwing .rej files around

Isn't -m useful here?  Or is it only useful in the three way merge 
situations involved in the use of qsave (as mentioned above)?  I don't 
know as I've only used it in those situations.

It would be nice if graphical merge tools could be given a file and its 
.rej and present the user with a suitable representation for resolving 
the rejections.  My apologies if they can already do this.

Peter
-- 
Peter Williams                                   pwil3058 at bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce