push return code broken?

[Martin Geisler]

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?

The change was put on the stable branch just a day or two before the
release. Sometimes we avoid changes because they could "break 1000's of
scripts" (despite having no idea if anybody is using this feature in a
script). Here we didn't and this actually breaks things here and there.


-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20120210/39e85fa8/attachment.asc>