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

Jim Meyering [off-list ref] writes:

Jakub Narebski [off-list ref] wrote:

quoted

Jim Meyering wrote:

quoted

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

quoted

quoted

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