[PATCH] hgext/mq - idempotent operations should return success

B Thomas bjthomas3 at gmail.com
Sat Feb 17 21:06:56 UTC 2007


On 2/17/07, Alexis S. L. Carvalho <alexis at cecm.usp.br> wrote:
>
> I've tweaked the patch a bit and pushed it to crew.  Thanks.


Great !  Thanks.  I appreciate your assistance and modifications.

There are some corner cases with guards that it doesn't really deal
> with.  E.g. say you have four patches (a, b, c and d) and none is
> applied.  If d is guarded by +foo and you do "hg qpush d", we return
> success, even though we don't leave d at the top (we can't push it since
> it's guarded).


If it wasn't clear before, it's probably clear now, that I don't use guards
much at this point and this was a weak spot in the patch. ;-)

Thanks for noticing this.

There's the open question about what regular commands should get a "q"
> variant - we certainly don't want all of qtip, qupdate, qmerge, qpull,
> qheads, etc..  So I'm not completely sure about qstatus - I've heard
> some people that think even qcommit was an error, while others would
> like a generic qrepo command.


I mostly agree, and am only making changes in places that I find to be
relatively useful and/or help avoid some level of pain/frustration/typing. I
concur that not every command needs a variant. I've been using mq a fair
amount with 20+ (and growing) repositories. These changes have come about as
a result of constant use of mq within scripts, makefiles, and general use.
I'm not on a mission to provide completeness so much as to make my life
easier. Submission of the patches is my attempt to help make others' lives
easier as well.

I have submitted 3 additional patches that are mq related (in separate
emails).  Add qstatus; add qfiles; and extend the range/usefulness of
[collections] in the web interface.

Thanks !
-b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20070217/2d50ec79/attachment.html>


More information about the Mercurial-devel mailing list