MQ usability
Peter Williams
pwil3058 at bigpond.net.au
Mon Aug 17 06:52:00 UTC 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