Re: Error pushing new branch: value too great for base (error token is...

From: Gaurav Chhabra <varuag.chhabra@gmail.com>
Date: Aug 11, 2015, 06:30 UTC
Message-ID: <CAGDgvc3kA4oC=gp7XoPZJNrQ=p6HoUiXgcECG_xdRR=uJ03+aQ@mail.gmail.com>
In-Reply-To: <CAPig+cTB0VU6rmLT1H7sPMNBPE0zKvWmMp_obS5VpZBAi2nYLA@mail.gmail.com>

Thanks for the detailed explanation Eric! That really helped clear my doubts. Also tried with "0x" and it's working fine however, as suggested by you, i will use '='

Thanks again! :)

On Tue, Aug 11, 2015 at 4:17 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:

Show 30 quoted lines

> On Mon, Aug 10, 2015 at 6:29 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> On Mon, Aug 10, 2015 at 2:54 AM, Gaurav Chhabra
>> <varuag.chhabra@gmail.com> wrote:
>>> Apologies for the delay in reply! I tried your suggestion and it
>>> works. Thanks! :)
>>>
>>> I'm curious why integer comparison is throwing error. Shouldn't i be
>>> comparing numbers with numeric operator?
>>
>> Yes, but shell doesn't treat hex numbers as numbers. So it will work
>> only if the string is a decimal number.
>
> This particular case deserves a bit more explanation. The expression
> in question was this:
>
>     if [[ "$new_sha" -eq "$NULL" ]]; then
>
> where 'new_sha' was 9226289d2416af4cb7365d7aaa5e382bdb3d9a89.
>
> In Bash, inside the [[ .. ]], it did attempt evaluating the SHA1 as a
> *decimal* number, however, when it encountered the "d", it complained
> that it was outside the allowed range of decimal digits ("0"..."9").
> Had the SHA1 been prefixed by a "0x", the [[...]] context would have
> dealt with it just fine.
>
> Outside the [[...]] context, arguments to -eq do need to be base-10 integers.
>
> Nevertheless, a SHA1 is effective an opaque value. There's little, if
> anything, to be gained by treating it as a numeric quantity, hence
> string '=' makes more sense than numeric '-eq'.