push return code broken?

[Matt Mackall]

On Thu, 2012-02-09 at 23:27 -0500, timeless wrote:
> It also broke at least Mozilla's mail suite's pull script, I know
> sp3000 and I played bug filing chicken and patch writing chicken for
> it on #mercurial

Alright, I've reverted the change for stable.

> On 2/9/12, Matt Mackall <mpm at selenic.com> wrote:
> > On Fri, 2012-02-10 at 00:11 +0100, Martin Geisler wrote:
> >> John Coomes <John.Coomes at oracle.com> writes:
> >>
> >> > Matt Mackall (mpm at selenic.com) wrote:
> >> >> On Fri, 2012-01-27 at 17:13 -0800, John Coomes wrote:
> >> >> > Matt Mackall (mpm at selenic.com) wrote:
> >> >> > > On Fri, 2012-01-27 at 18:26 +0100, Markus Zapke-Gründemann wrote:
> >> >> > > > Hi,
> >> >> > > >
> >> >> > > > could it be that the return code of push is always zero? I
> >> >> > > > created the following test where the last push operation fails
> >> >> > > > because it returns zero. But push docs say "Returns 0 if push
> >> >> > > > was successful, 1 if nothing to push.".
> >> >> > >
> >> >> > > Yes, this seems to be a bug.
> >> >> >
> >> >> > FWIW, I'd rather see the docs changed than the return code. The
> >> >> > mirror command, pull, returns 0 if nothing was pulled:
> >> >> >
> >> >> >     Returns 0 on success, 1 if an update had unresolved files.
> >> >>
> >> >> Well that's actually its own surprise, as I've always said the
> >> >> behavior of pull -u should match "hg pull && hg update" and not "hg
> >> >> pull; hg update" (ie don't update if nothing was pulled). Implicit in
> >> >> that is returning a failure code if nothing is set.
> >> >>
> >> >> Currently we have the following return codes if nothing is found:
> >> >>
> >> >>                 commit   incoming    outgoing      pull     push
> >> >> intended           1        1           1            1       1
> >> >> documented         1        1           1            0       1
> >> >> actual[1]          1        1           1            0       0
> >> >>
> >> >> The behavior of push is especially surprising as the code sure reads
> >> >> like it ought to work.
> >> >>
> >> >> The use of non-zero return codes for "nothing found" appears in a
> >> >> bunch of places in Mercurial. This traces its origins to the standard
> >> >> behavior of Unix grep which returns 1, thus making a whole bunch of
> >> >> scripty things possible that would otherwise be quite tedious. It was
> >> >> always the intent that you could do:
> >> >>
> >> >>  hg pull && do-buildy-things
> >> >
> >> > I usually use the idiom:
> >> >
> >> > 	hg pull || react-to-the-error
> >> >
> >> > and a no-op pull isn't an error. Obviously, it's possible to cope with
> >> > an empty pull returning 1, but it's no longer the trivial statement
> >> > above (same applies to 'hg pull && build-it' if it returns 0).
> >> >
> >> > I see now that you've pushed the change, so it's moot.
> >>
> >> This change has caused problems in our Jenkins build for JavaHg: when a
> >> single 'hg pull' returns 1, the build is aborted. It has also caused
> >> problems for a CruiseControl.NET build reported here:
> >>
> >>   http://stackoverflow.com/q/9215000/110204
> >>
> >> I know 093b75c7b44b is marked as backwards incompatible, but maybe we
> >> should think more carefully about this next time?
> >
> > Agreed. So, should we revert it for 2.1.1 or live with the damage?
> >
> > --
> > Mathematics is the supreme nostalgia of our time.
> >
> >
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at selenic.com
> > http://selenic.com/mailman/listinfo/mercurial-devel
> >
> 


-- 
Mathematics is the supreme nostalgia of our time.