incoming exit status

Vadym Chepkov vchepkov at gmail.com
Wed Nov 10 12:59:14 CST 2010


On Nov 10, 2010, at 1:44 PM, Mads Kiilerich wrote:

> On 11/10/2010 07:27 PM, Vadym Chepkov wrote:
>> 
>> 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"
> 
> Then don't use it - or handle the exit codes explicitly.
> 
> The behavior is intentional. See "hg help incoming" and perhaps http://mercurial.selenic.com/bts/issue2189
> 

I guess I should have searched if this issue was raised or not
But I believe the conclusion in the thread is 
"
...
any success cases where it exits with non-zero; if they exist, they are bugs and
should also be reported.
...
"



> /Mads
> 
>> 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"
>> 
>> either you have output or not, no?
>> 
>> Vadym
>> 
>> 
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial
> 



More information about the Mercurial mailing list