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
See for example this query about a hypothetical "hg stash" extension, which
would be the equivalent to the git-stash command:
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"):
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.
More information about the Mercurial-devel