Changes in 2.1 for status code for pull requests
mg at aragost.com
Fri Feb 10 04:21:50 CST 2012
Christopher Petrilli <petrilli at amber.org> writes:
> (BTW, if this should be on the developer mailing list, let me know)
This is also being discussed on the devel list right now:
It seems like a better place to discuss it, so I've set the
> When I updated from Mercurial 2.0.2 to 2.1, I ran into a problem with
> Python's pip tool for installing packages, and tracked it down to a
> change in how Mercurial reports exit values in changeset
> 16039:093b75c7b44b: "pull: return 1 when no changes found". I wonder
> about the reasoning for this as it seems to have conflated two
> different situations with an identical exit codes:
> 1. no changes found or
> 2. update had unresolved files
> These two things seem quite different to me.
They seem very different to me too :) As I understand it, the idea
behind the exit codes was that
hg pull && hg update && make
should make sense. If nothing was pulled, there's no need to update and
so no need to build anything. So 'hg pull' was intended to return 1 when
nothing was pulled. The return code was changed in Mercurial 2.1 so that
hg pull -u == hg pull && hg update
which means that the above can be shortened to
hg pull -u && make
I believe that was the rationale.
> The first implies a clean repository (even if there's no changes),
> where-as the second implies a problem. This appears conflicts with
> standard UNIX exit codes, which have historically used 0 to mean "OK"
> and other values for errors or conditions that need to be responded
> to. In this situation, however, "no changes" don't require any kind of
> response. As a point of reference, git returns 0 for "no changes".
Your point about requiring human intervention or not is very sensible.
Running 'hg update' even when there's nothing to update it not a big
problem. I see in your table that 'hg update' return 0 even when there
was nothing to update, so 'make' would run in the above example. That's
a waste of resources, but again nothing that requires human attention.
> Looking at the response codes for various Mercurial commands:
> COMMAND RETURN 0 RETURN 1
> add Success ?
> branch Success ?
> clone Success ?
> commit Success Nothing changed 
> copy Success Error
> grep Match (success?) Nothing found
> heads Match Nothing found
> merge Success Unresolved files
> outgoing Outgoing files No outgoing files
> push Success Nothing to push
> recover Success Nothing to recover/verify failed 
> remove Success Warnings
> rename Success Errors
> resolve Success Failed resolve attempt
> rollback Success No rollback data
> update Success Unresolved files
> verify Success Error
>  This could be interpreted as an error condition because you
> normally only run commit when you know you have something to commit,
> and therefore likely forgot to run add.
>  I would argue both of these require human intervention. You don't
> run recover unless you think something's wrong, so if there's nothing
> to recover it would generally be something wrong.
> It seems to me that the "correct" behavior for 'hg pull' would be to
> consider "no changes found" to be success, and "update had unresolved
> files" to be the error condition. The first doesn't require human
> intervention, but the 2nd does and only matters if you've also
> included '--update' in your command.
> Did I miss some logic here, or? Before making a change to pip so that
> it can continue to function, I want to understand this better so that
> we don't accidentally make a bad logic mistake in the code.
Professional Mercurial support
More information about the Mercurial-devel