[PATCH] hgext/mq - idempotent operations should return success
Alexis S. L. Carvalho
alexis at cecm.usp.br
Sat Feb 17 01:39:46 CST 2007
I've tweaked the patch a bit and pushed it to crew. Thanks.
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
If we repeat the "hg qpush d", we return an error, but the message we
print doesn't really explain why the push failed (this would probably
require tweaking with explain_pushable a bit). (Your patch printed a
different message here, but I felt it didn't really explain things
either, so I left it with the same message from a regular "hg qpush"
Thus spake B Thomas:
> Once we've reached some sort of final
> version of this, I have additional patches that I've been using to implement
> qstatus and qfiles commands. Assuming interest, I'll post them as well.
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.
Assuming qfiles answers the question of what files are touched by patch
foo, I think it'd be a nice addition - you can do that right now with hg
status -n --rev, but that's a bit too cumbersome.
> The single misunderstanding on my part is in the qpop change. You suggest:
> >Here I'd also prefer a single self.ui.warn (probably even with the
> >original message) followed by a "return not (patch or all)".
> I was unclear on what you meant by "single". I modified the message and
> return, but... what else ?
Take a look at what I pushed. Essentially, instead of:
print some message
print a slightly different message
print one message
return not all
More information about the Mercurial-devel