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

[Dan Villiom Podlaski Christiansen]

Greg Ward <greg-hg at gerg.ca> wrote:

»Fail.  Also fail if no .hg/patches directory and no .hg/patches/.hg repository.«

For what it's worth, I'd consider behaviour like that yet another argument for not installing such a command. There's little point in installing a script that always fails unless the user changes the configuration…

»Anything to do with the stack of patches would remain where it
currently is, the "hg q*" commands.  The "mq" script would only deal
with version control on the .hg/patches directory.  I.e. it replaces
the shell alias "hg -R $(hg root)" that is recommended by The Book.«

MQ already has an excessively complex interface, and I don't see how your suggestion does anything to deal with this. Furthermore, as scripts in contrib aren't installed by default, it wouldn't help users who install from anything other than the source.

»That is a valid point.  More so when you consider that if mq itself is
advanced, then versioning .hg/patches is even more advanced.  I know
it took me a few weeks to get used to the workflow.  (Although now I
like it.)«

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.

»Well, I still want to write the script.  Or have someone write it for
me.  If nothing else, it should be more efficient than the shell
alias, since it only requires one fork and one Python interpreter.  If
it winds up in contrib rather than a full-fledged sibling of 'hg'
itself, that would be OK by me.«

I won't try to stop you writing that script :) (That'd be quite pointless and rude, and probably impossible too…)

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? 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.
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.

I hope I'm making sense :)


--

– Dan Villiom Podlaski Christiansen
stud.scient., danchr at gmail.com