push return code broken?

[timeless]

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

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
>

-- 
Sent from my mobile device