MQ merging

[Mark Williamson]

> > This is the purpose of "hg qsave" and "hg qpush -m"...
>
> But this is a very cumbersome and error-prone UI. If Bryan admits that
> using this system is too much of a hassle to bother with, how can we
> expect anyone to use it?

It's also not very discoverable ;-)  I just found out about it by reading the 
Mercurial book, having previously been rebasing by qpopping, pulling, 
qpushing, then fixing the rejects manually.

I was quite excited to find out that there was an interface for doing proper 
merges and would love to use this.  It would be nicer if it was a bit easier 
to apply, though.

> but using the clean 3-way merge infrastructure. This command would be
> the MQ equivalent of 'hg fetch', i.e. "please update me to the latest
> upstream version with my patches reapplied". 'hg qfetch' perhaps.

Again, basically what I was wishing for too.

> > you have to explicitly save the old set of correctly-applied
> > changesets, or else the chances that the old parent will still be
> > around is pretty slim.
>
> Not in my experience. Generally if I have a patch sitting around at the
> top of the queue, I developed it against some permanent changeset, that
> was probably tip of the official repository at the time. When I want to
> rebase it, I will do so against some descendant of the original parent.
> So the original parent is easily accessible. There is no need to keep
> any special information in the patch itself beyond the node ID of the
> original parent, since the correctly-applied MQ changesets can be easily
> reconstructed at any time.

That's what I would have thought.  I have a feeling we're maybe missing some 
detail in Benjamin's original comment here?

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)