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

From: Junio C Hamano <junkio@cox.net>
Date: May 22, 2006, 08:16 UTC
Message-ID: <7vr72meapg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87psi6h5kv.fsf@rho.meyering.net>

Jim Meyering <jim@meyering.net> writes:

Show 5 quoted lines

> Jakub Narebski <jnareb@gmail.com> wrote:
>
>> Jim Meyering wrote:
>>
>>> It'd be better to produce a diagnostic and fail:

I agree with you that we are loose in integer overlaps. Some of them do matter, some don't. The xrealloc one is, as you said, borderline, I think, but more serious than this one. This one is worth fixing only if/because the fix is obvious and does not hurt the code otherwise (e.g. does not decrease portability, does not hurt usability, etc.).

Show 9 quoted lines

>>>
>>>   $ ./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?

You shouldn't have to care about nor refer to the root commit that often (if ever) in a real project. It is handy to be able to refer to it when your repository is very young and you are toying with git more than you are working on your own project that is managed by git. But in such a case, finding it once and tagging it is so easy and efficient that you would not want to traverse the whole history every time you would want to refer to it.

In other words, I think Jakub was just joking, and this particular objection does not qualify as "hurt usability" criteria I said in the above.