push return code broken?

[Matt Mackall]

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.