incoming exit status

[Jason Harris]

On Nov 10, 2010, at 9:10 PM, Haszlakiewicz, Eric wrote:

>> -----Original Message-----
>> From: Vadym Chepkov [mailto:vchepkov at gmail.com]
>> 
>> On Nov 10, 2010, at 1:19 PM, Haszlakiewicz, Eric wrote:
>> 
>>>> -----Original Message-----
>>>> From: mercurial-bounces at selenic.com [mailto:mercurial-
>> bounces at selenic.com]
>>>> 
>>>> I noticed hg incoming returns 1 if there are no any incoming changes.
>>>> What is the reason? I don't think it's an error condition and it breaks
>>>> ability to automate unattended builds.
>>> 
>>> I think it's specifically so you can easily distinguish between the
>> changes-available and no-changes-available cases.  I have scripts that
>> depend on this so I don't have to try to decode the output, which would be
>> very sensitive to the exact messages emitted and thus error prone.
>>> Actual errors cause hg to exit with a return value higher than 1.
>>> 
>>> eric
>>> 
>> 
>> well, that does't work well with shell's "set -e"
> 
> It's not as simple as just running the hg incoming command, but you can always explicitly check for the return value:
> hg incoming || _err=$?
> if [ ! -z "$_err" -a $_err -gt 1 ] ; then
> 	exit $_err
> fi
> 
>> and you can rely on output if you specify template, at least I would expect
>> it will be predictable
>> hg -q incoming --template "{rev} {files}\n"
> 
> That only affects what you get if there's actually changesets available, not what you see when there's nothing new to pull in. 
> 
>> either you have output or not, no?
> 
> No, "hg incoming" produces output all the time.
> 
> Regardless of whether the output is consistent or now, it's needlessly complex to have to parse it just to get a simple status about whether there were changes available.  
> Trying to parse the output also opens you up to unusual text screwing with you.  e.g., say you look for the phrase "no changes found", but someone commits a change with a description that says something like "Fix the 'no changes found' message to say foo instead"
> Also, even if you omit all potentially problematic data through a template, you're not even guaranteed that the output will say "no changes found" when there's nothing to pull in.
> Someone can decide that they want to see messages in their native language:
>> LC_MESSAGES=fr_FR hg incoming
> comparaison avec https://myserver.example.com/foo
> searching for changes
> aucun changement trouv?


Well you can just use 'hg --quiet incoming' to ensure you don't have any chatty messages... If thats the empty string you don't have any incoming changesets. Simple.


On Nov 10, 2010, at 8:50 PM, Matt Mackall wrote:
> On Wed, 2010-11-10 at 20:08 +0100, Jason Harris wrote:
>> Personally, I still feel that a valid command, that has executed in a valid way, returning a valid result of (nothing) should have an exit code of 0.

> Simply put, you're wrong. The grep command was created on March 3, 1973,
> so there's decades of historical and standards precedent for giving
> useful exit codes.

(Maybe grep is more of an aberration here than a paragon of consistency with the wider world?  Are there many other examples of this behavior?  From what I can tell by googling it appears not... Eg things like ' touch bob; wc bob; echo $? ' yields an exit code of 0. As does the unix 'find' command when it doesn't find any matches, etc..)

If you look around on various web pages you will see most of them use words like (exit code 1: catchall for general errors, miscellaneous errors, such as "divide by zero", etc. See eg (Your google foo may very) :)

http://www.freebsd.org/cgi/man.cgi?query=sysexits&sektion=3
http://www.faqs.org/docs/abs/HTML/exit-status.html#EXITSTATUSREF
http://www.faqs.org/docs/abs/HTML/exitcodes.html#EXITCODESREF
http://en.wikipedia.org/wiki/Exit_status

(Of course they mention that there are exceptions, and I guess grep is one such exception to the general rule, so its not unheard of...)

(I checked 'cvs -n update' (which is fairly equivalent to hg incoming) and it has an exit code of 0 even if there isn't anything to update. I wonder what svn, git, bazaar and others do with equivalent-ish commands...?)

Since this has been raised by a number of people over time its clearly something that a subsection of people find "odd" or out of the ordinary.


> There's also now half a decade of precedent _in Mercurial itself_ and
> people in this very thread have already pointed out that they depend on
> that behavior.


Thinking about this more, perhaps incoming and outgoing should have the option '--count' which would have the effect that instead of returning a verbose message, it would simply return the incoming / outgoing count. In fact I internally to MacHg use:
  hg incoming --quiet --template "-"
And then count the string length of the result to get the incoming / outgoing counts.

Cheers,
  Jas