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