pwil3058 at bigpond.net.au
Mon Aug 10 19:18:49 CDT 2009
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 Williams pwil3058 at bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
More information about the Mercurial-devel