[PATCH 0 of 3] Add option for operating on queue repository

Dan Villiom Podlaski Christiansen danchr at gmail.com
Sat Jul 11 15:46:26 CDT 2009

On 11/07/2009, at 22.07, Dirkjan Ochtman wrote:

> Just to weigh in: I dislike this just because I think it unreasonably
> complicates the UI. It adds an option to a large number of commands,
> complicating documentation for each of those commands. I also think
> only a relatively small part of the mq-using population does actually
> version their MQ (other than maybe doing qcommit just for the
> backups). I also agree a separate 'mq' command is probably not the
> best solution, although at least that variant doesn't complicate hg
> itself.

Point taken. *sigh*

> It's a hard UI issue, and I'm not sure what the best solution here is.
> The best option I can think of right now is a hg
> qrepo/qcontrol/qsomething that has --push, --pull, --status and maybe
> a few other useful actionable options (though that's somewhat ugly
> because the acceptable option set changes somewhat based on what's in
> it).

For some reason, the prefix concept strikes me as, well… somehow wrong  
or ugly. I'm not sure why, but it just does :/

One alternative would be to implement it as a hidden option.  
Currently, options marked as DEPRECATED are hidden by default, and in  
an earlier patch, I expanded that behaviour to commands. We could  
treat options marked as ADVANCED — or something — similarly; hide them  
from either non-verbose or non-debug output.

To not leave the option un(der)documented, it could be described in  
the MQ extension documentation, along with a list of commands  
supporting it. Better?


Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090711/2ee7ed02/attachment.bin 

More information about the Mercurial-devel mailing list