[PATCH 0 of 3] Add option for operating on queue repository
greg-hg at gerg.ca
Tue Jul 7 14:13:14 CDT 2009
On Tue, Jul 7, 2009 at 11:49 AM, Dan Villiom Podlaski
Christiansen<danchr at gmail.com> wrote:
> Versioning a patch queue doesn't have to be any more advanced, difficult or complicated
> than just dealing with the patch queue itself. I'd say the current difficulty is caused by the
> limited interface to the queue repository.
Right. And either -Q or '/usr/bin/mq' addresses that difficulty.
(BTW, most of your other points *are* perfectly valid. I'm not
utterly opposed to -Q, I'm just trying to make sure that one obvious
alternative gets a good airing.)
> Still, I don't quite understand your objections to my approach; could you perhaps elaborate?
> Do you consider the approach difficult to maintain, fragile or something?
It just seems a bit invasive to go adding the same option to many
different commands. It feels like a potential arms race: someone adds
new command 'foo', and then we all have to stop and think, "should MQ
add -Q to this command?". That's annoying for core commands, and
impossible for commands added by extensions.
> In my opinion, an
> option for dealing with the queue repository has many advantages:
> 1) Generally, options are easily discovered and simple to type and work with.
> 2) The option consistent: -Q/--queue has the same meaning for every command recognising it.
Both true. #1 in particular argues for -Q over 'mq'.
> 3) The option could lead to less clutter, by either hiding, deprecating or removing some of the
> commands exposed by MQ. The obvious example of this is qcommit, but it could also apply
> to qinit and qclone.
Factoring out an 'mq' command has the same benefit: it would
theoretically let us deprecate/eliminate qcommit and qclone. So -Q
doesn't really have any benefit there relative to 'mq'. They both
beat the status quo.
> I hope I'm making sense :)
More information about the Mercurial-devel