atom feed8 messages in com.selenic.mercurial-develRe: push return code broken?
FromSent OnAttachments
John CoomesJan 27, 2012 5:13 pm 
Isaac JuradoJan 28, 2012 2:58 am 
Markus Zapke-GründemannJan 28, 2012 9:15 am 
Martin GeislerFeb 9, 2012 3:11 pm 
Matt MackallFeb 9, 2012 3:55 pm 
timelessFeb 9, 2012 8:26 pm 
Matt MackallFeb 10, 2012 2:34 pm 
Nikolaj SjujskijFeb 14, 2012 9:09 am 
Subject:Re: push return code broken?
From:Matt Mackall (
Date:Feb 10, 2012 2:34:20 pm

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 <> wrote:

On Fri, 2012-02-10 at 00:11 +0100, Martin Geisler wrote:

John Coomes <> writes:

Matt Mackall ( wrote:

On Fri, 2012-01-27 at 17:13 -0800, John Coomes wrote:

Matt Mackall ( wrote:

On Fri, 2012-01-27 at 18:26 +0100, Markus Zapke-Gründemann wrote:


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:

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?