Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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

From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:45:11

Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help