Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'

["Shawn O. Pearce" <spearce@spearce.org>]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> 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()?

No.  Isn't match_digit() in the code path used by GIT_COMMITTER_DATE?
We should handle dates as far back as Sat Mar 3 01:46:40 1973 as
seconds-since-epoch to support conversion tools which bring in old
history that predates Git's inception.

If anything the reflog code should change its test to be the same
"8-digit" rule.  A reflog of 100,000,000 entries requires at least
7.9G, a threshold which isn't utterly insane (as it fits on a DVD-R)
but still is not really reasonable for current Git reflog.

-- 
Shawn.