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

From: Jakub Narebski <jnareb@gmail.com>
Date: May 21, 2006, 21:42 UTC
Message-ID: <e4qmsn$3mv$1@sea.gmane.org>
In-Reply-To: <87d5e7hxhl.fsf_-_@rho.meyering.net>

Jim Meyering wrote:

Show 20 quoted lines

> 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.

-- 
Jakub Narebski
Warsaw, Poland