"Shawn O. Pearce" [off-list ref] writes:
The value 1112911993 was chosen for the limit as it is the commit
timestamp for e83c516331 "Initial revision of "git" ...". Any
reflogs in existance should contain timestamps dated later than
the date Linus first stored Git into itself, as reflogs came about
quite a bit after that.
Additionally a reflog with 1,112,911,993 record entries is also
simply not valid. Such a reflog would require at least 87 TB to
store just the old and new SHA-1 values. So our randomly chosen
upper limit for @{nth} notation is "big enough" that users will
not run into it by accident.
Hmm, would we want to apply that logic to replace the magic "8-digit" rule
in date.c::match_digit()?