MQ usability

Peter Williams pwil3058 at bigpond.net.au
Mon Aug 17 01:52:00 CDT 2009


On 17/08/09 11:02, Peter Williams wrote:
> On 16/08/09 20:08, Dirkjan Ochtman wrote:
>> On Tue, Aug 11, 2009 at 02:18, Peter Williams<pwil3058 at bigpond.net.au>
>> wrote:
>>> 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.
>>
>> You could just use the rebase extension to rebase applied patches to
>> the new tip. Seems much easier to use and remember (and is more
>> accessible, IMO).
>
> I was unaware of the existence of 'rebase' but now that I am I'll give
> it a try. I'll admit that the procedure described for 'qsave' et al is a
> little complicated which is why I put the special menu (for it) in
> gwsmhg's MQ page.

I've given this a try and I like the simplicity of it BUT it left the 
repository in a bit of a mess in that the change sets representing the 
patch series before the rebase are still there and the following hook 
was triggered.

# Prevent "hg push" if MQ patches are applied.
preoutgoing.mq-no-push = ! hg qtop > /dev/null 2>&1

So I think it is promising but needs some work before I'd use it for real.

Also, as does the 'qsave' recipe when used with 'push -ma', it suffers 
from the problem of confusing the user if the patch series is large and 
there are a lot of merges that require using the visual merge tool to 
resolve.  To elaborate, it can be quite confusing to be asked to resolve 
a merge without knowing which of the patches is in question.  To solve 
this issue with the recipe, I just apply/merge the patches one at a time 
using 'qpush -m' rather than doing them in one hit with 'qpush -ma'. 
This has the added advantage that I don't have to do all the changes in 
one sitting which is useful when it's a large change that could require 
several days to do.

The confusion problem above could probably be solved by adding the patch 
name to the 'merging <file>' message emitted by 'rebase' and I assume 
the --abort and --continue option could be used to break up a session 
(but the documentation on this is a bit scant and the details of how to 
use them aren't something I fancy determining by experimentation).

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

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


More information about the Mercurial-devel mailing list