atom feed13 messages in com.selenic.mercurial-develRe: push return code broken?
FromSent OnAttachments
Markus Zapke-GründemannJan 27, 2012 9:25 am 
Matt MackallJan 27, 2012 3:47 pm 
John CoomesJan 27, 2012 5:13 pm 
Isaac JuradoJan 28, 2012 2:58 am 
Markus Zapke-GründemannJan 28, 2012 9:15 am 
Matt MackallJan 29, 2012 1:35 pm 
John CoomesJan 30, 2012 2:31 pm 
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 
Martin GeislerFeb 15, 2012 5:35 am 
Subject:Re: push return code broken?
From:Matt Mackall (mp@selenic.com)
Date:Jan 29, 2012 1:35:24 pm
List:com.selenic.mercurial-devel

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

Matt Mackall (mp@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

[1] Note that if you have the pager extension enabled, it might swallow the actual return code too!