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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 10, 2015 at 6:29 PM, Jacob Keller <jacob.keller@xxxxxxxxx> wrote:
> On Mon, Aug 10, 2015 at 2:54 AM, Gaurav Chhabra
> <varuag.chhabra@xxxxxxxxx> 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'.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]