Re: don't accept bogus N in `HEAD~N'

From: Jim Meyering <jim@meyering.net>
Date: May 22, 2006, 07:38 UTC
Message-ID: <87psi6h5kv.fsf@rho.meyering.net>
In-Reply-To: <e4qmsn$3mv$1@sea.gmane.org>

Jakub Narebski <jnareb@gmail.com> wrote:

Show 26 quoted lines

> Jim Meyering wrote:
>
>> In a very shallow audit, I spotted code where overflow was not detected.
>> But it's hardly critical.
>>
>> Currently,
>>
>>   git-diff HEAD HEAD
>>
>> is equivalent to this
>>
>>   git-diff HEAD HEAD~18446744073709551616   # aka 2^64
>>
>> Exercising git-rev-parse directly, currently I get this:
>>
>>   $ git-rev-parse --no-flags --sq HEAD~18446744073709551616
>>   '639ca5497279607665847f2e3a11064441a8f2a6'
>>
>> It'd be better to produce a diagnostic and fail:
>>
>>   $ ./git-rev-parse --no-flags --sq -- HEAD~18446744073709551616 /dev/null
>>   fatal: ambiguous argument 'HEAD~18446744073709551616': unknown revision or filename
>
> Wouldn't it remove ability to say "to the root commit"?
> One can do it now I guess exactly by specyfying overly large N.
> Although there should probably be some limit... or not.

Do people really use HEAD~<VERY_LARGE_INTEGER> to refer to the root? Any who do that will find it surprising that HEAD~18446744073709551616 is currently interpreted just like `HEAD~0'. And HEAD~18446744073709551617 just like HEAD~1, etc.