Changes in 2.1 for status code for pull requests

[Martin Geisler]

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:

  http://markmail.org/message/yqitgmkp3xutmvnq

It seems like a better place to discuss it, so I've set the
Mail-Followup-To header.

> 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 [1]
> 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 [2]
> remove      Success                     Warnings
> rename      Success                     Errors
> resolve     Success                     Failed resolve attempt
> rollback    Success                     No rollback data
> update      Success                     Unresolved files
> verify      Success                     Error
>
> [1] 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.
>
> [2] 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.
>
> Thanks,
> Chris

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/customer-projects/