cboos at neuf.fr
Tue Aug 11 03:13:35 CDT 2009
Dirkjan Ochtman wrote:
> On Mon, Aug 10, 2009 at 20:21, Christian Boos<cboos at neuf.fr> wrote:
>> I'm not enthusiastic about this part of the proposal, I use the above 4
>> commands all the time and frankly they're quite trivial/automatic to learn,
>> so you don't buy much reduction in complexity by removing them.
>> OTOH I don't use qseries often if at all, as all I want to know is what is
>> currently applied or not. So I do 'hg qapp', followed by 'hg qunapp'.
> You can just use qapp and qunapp instead of qprev/qnext, right? That's
> the idea. Having them around makes MQ quite cluttered, so I think a
> little more focus would be good. Obviously if you have some use case
> that's not covered by other commands, let's hear about it.
The point here is that with those commands you just want one line of
result, i.e. a terse answer.
So for qnext, you could do "hg qunapp | head -1" (i.e. the direct answer
to "what's the next patch").
Similarly, qtop could be "hg qapp | tail -1".
And qprev could be... well, "hg qapp | tail -2" and see if there are two
lines, one or zero?
To me, it's a loss in usability. OTOH, I was the only one interested in
adding "-p" to qprev/qnext to also see the actual content of the
prev/next patch, so maybe I'm special ;-)
> I rather like the idea that qrefresh is strictly additive (records
> more changes) and qsplit could be the opposite. Two focused commands
> are worth more than one kitchen sinkish do-every-type-of-modification
> possible command.
A clear delineation like that would indeed make sense. Let me try to
express the proposed semantic in more details, in order to check if I
got you right.
New behavior for qref would be:
- "qref <files>" or "qref -I <included>" would just add the changes in
<files> or <included> patterns, but will not include the changes from
any other files, nor will it remove any currently recorded change.
- "qref" would be a shortcut for "qref -I '**'" (i.e. get everything in
- "qref -X <excluded>" would add changes from every files but the
<excluded> ones, i.e. this won't remove other changes currently recorded
in the patch.
- "qsplit <files>" or "qsplit -I <included>" would just remove the
changes in the patch concerning <files> or <included> patterns and make
them local changes (.rej files if there are already local changes there,
- "qsplit" would be a shortcut for "qsplit -I '**'" (i.e. remove
everything from the patch)
- "qsplit -X <excluded>" would remove every changes from the patch but
those belonging to the <excluded> files, which will be kept in the patch
If it's like this, then I'm enthusiastically supportive.
>> The item with "-f" reminds me of another related discussion: all the MQ
>> commands qpush/qpop/qgoto could be made consistent when faced with local
>> changes and are given the '-f' flag, as currently each behaves slightly
>> differently. To me that's one of the real difficult aspect of MQ.
> Can you outline where the behavior differs?
Both qpush -f and qpop -f will leave local changes as such, except for
the local changes in files that are also modified by (one of) the
patch(es). In that case qpush -f will integrate the local changes in the
patch but qpop -f will discard them (they're *lost*). Note that the help
of qpush currently says otherwise. I guess qpush could be fixed so that
it also discards local changes instead of integrating them, just to be
consistent with the doc and qpop, but that behavior is not terribly
useful. I would much prefer that you could keep your local changes
intact while moving around in the patch stack. Hence:
>> One simple idea to improve upon this would be to first stash all the local
>> changes in a local_changes.diff file (only if that file doesn't already
>> exist of course), and then perform the operation (qpush/qpop/qgoto). If the
>> command succeeds, try to apply the local_changes.diff again and do a qref if
>> something has been merged successfully. If the command fails, inform the
>> user that the local changes were saved in that local_changes.diff file.
>> After fixing manually the issues with the command, the user can try to apply
>> (manually or qimport) the former local changes again.
> This sounds pretty complex to me...
But actually I think I just need to use the attic or shelve extension
here, and do "shelve; (qpush/qpop/qgoto); unshelve" when I have some
local changes that I want to move into a patch elsewhere in the stack.
More information about the Mercurial-devel