Changes in 2.1 for status code for pull requests

Axel Hecht l10n.moz at googlemail.com
Tue Apr 17 13:04:50 CDT 2012


Martin,

not following the devel list, sorry. I'm just hitting that apparently the
pull return code got backed out, but AFAICT, the corresponding change to
the push return codes wasn't?

Axel

2012/2/10 Martin Geisler <mg at aragost.com>

> 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/
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120417/12f4a137/attachment.html>


More information about the Mercurial-devel mailing list