dirkjan at ochtman.nl
Mon Aug 10 15:04:26 CDT 2009
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.
> Good ideas. Though adding an '--amend' flag to qrecord for reworking the
> current patch would perhaps be a better solution than a new qsplit command.
> IIRC, there was also a proposal in the past to integrate qrecord into qnew
> via an '-i/--interactive' flag.
> The "qsplit"/"qrecord --amend" idea could then become "qrefresh -i".
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
> 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?
> 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...
More information about the Mercurial-devel