MQ usability

Stuart W. Marks smarks at smarks.org
Mon Aug 10 18:20:54 CDT 2009


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:

Thanks for starting this discussion. I also feel that MQ is extremely useful 
and quite powerful. However, it's deficient in some areas as well. Some 
enhancements would be nice.

> - remove qgoto, qnext, qprev, qtop: this functionality is already
> covered quite well by qpop, qpush, qseries and log.

These add a certain amount of clutter, but they don't really complicate mq very 
much. So I don't think removing them will help very much. Indeed, one could 
replace qgoto with a script that that's implemented in terms of qseries and 
qpush/qpop but this doesn't really seem like a step forward.

> - possibly remove qsave/qrestore as well, since no one seems to use
> them (and many people get confused by them).

Like others, I don't use these, and I'm not actually sure what they do. I think 
documentation might help here. The current help docs are pretty terse, and I've 
never gotten around to experimenting or reading the source code to understand 
what they actually do. They might be quite useful for all I know.

> - 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.
> 
> - add a qsplit command to deal with the actual usage of qrefresh for
> excluding hunks (interactive mode for this would rock even more).

I haven't specifically run into this problem with qrefresh, but I have run into 
issues with managing which chunks of changes are in which patch. For example, 
at work we version our NetBeans project files, but for the most part I want to 
keep these changes separate from the rest of my changes. I suppose I could use 
qrefresh -X but usually I just end up editing the patch file manually.

Another issue I often run into is editing some files, and then realizing I have 
the wrong patch at the top. I typically qnew -f, then qpush/qpop to the "right" 
patch, and then qfold it in. It would be nice to make this simpler somehow.

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

For what it's worth, I end up using qnew -f more often than qnew without -f.

> - make qpush try a merge instead of throwing .rej files around

Yes, this would be very nice. As a workaround I've done the following: try to 
remember the previous rev where the patch applied without conflicts; update to 
that rev; push the patch (which creates a new head); merge the heads; and then 
somehow massage this back into a working patch on the tip. Basically this is a 
roundabout way of rebasing a patch. An essential piece of this seems to be 
having MQ record a base rev against which the patch is known to apply successfully.

> Any thoughts?

I think it would be helpful to focus the discussion on how people currently use 
MQ and what problems they've run into, and use that to drive changes into MQ. 
This would be in preference random piecemeal proposals like getting rid of 
qgoto in order to remove clutter. (I agree that MQ is somewhat cluttered, but I 
don't think that's it's biggest problem.)

With that in mind, here's my list.

1) Managing which changes are part of which patch. (Described above.)

2) Dealing with conflicting patches and .rej files. (Described above.)

3) Ordering of patches. I tend to use MQ for staging of multiple independent 
patches. In this usage pattern the ordering of the patch queue gets in the way. 
The qguard/qselect mechanism seems too cumbersome to me. So I just end up 
editing the series file.

4) Temporary storage/reshuffling of changes.

This one is a bit vague but there are clearly some problems here. There are 
extensions attic, shelve, pbranch, and a suggested stash extension that solve 
different aspects of this problem. Maybe it would make sense to integrated the 
extensions into MQ somehow, but I seem to recall the proponents of those 
extensions saying that they use both the extension and MQ, so they should 
remain independent.

See for example this query about a hypothetical "hg stash" extension, which 
would be the equivalent to the git-stash command:

http://selenic.com/pipermail/mercurial/2008-January/016560.html

The upshot is that MQ is much more powerful, but it's also much more complex, 
and this seems to be one of the few areas where git is simpler than hg.

Another related problem was raised just last week ("partial commits"):

http://selenic.com/pipermail/mercurial/2009-August/027088.html

Basically the guy had several files edited, and he wanted to commit and push 
one of them. Unfortunately there were new changes in his default-push repo, so 
he had to pull them first. But now he can't merge, since he has uncommitted 
changes! Using the attic extension seems to be the most promising. But from 
MQ's point of view, the problem is that MQ was pretty quickly dismissed from 
the discussion, probably because it's too complex and hard to learn and explain.

***

Anyway, thanks again for starting this discussion. I'm looking forward to 
helping to improve MQ.

s'marks


More information about the Mercurial-devel mailing list