MQ usability

[Christian Boos]

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 
the patch)
 - "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.

Conversely:
 - "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, 
or abort?)
 - "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.

-- Christian