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

[Greg Ward]

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 :)

Absolutely!

Greg