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

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

[Shawn O. Pearce]

As we support seconds-since-epoch in $GIT_COMMITTER_TIME we should
also support it in a reflog @{...} style notation.  We can easily
tell this apart from @{nth} style notation by looking to see if
the value is unreasonably large for an @{nth} style notation.

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.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 sha1_name.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 4fb77f8..e25f56a 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -349,7 +349,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 			else
 				nth = -1;
 		}
-		if (0 <= nth)
+		if (1112911993 <= nth) {
+			at_time = nth;
+			nth = -1;
+		} else if (0 <= nth)
 			at_time = 0;
 		else {
 			char *tmp = xstrndup(str + at + 2, reflog_len);
-- 
1.6.0.96.g2fad1.dirty

-- 
Shawn.

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

[Junio C Hamano]

"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()?

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

[Shawn O. Pearce]

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.

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

[Alex Riesen]

Shawn O. Pearce, Wed, Aug 20, 2008 01:44:33 +0200:
> 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.

Maybe I'm missing something, but aren't unsynchronized clocks a common
thing in personal computing? Even maybe less common, but noticably
frequent, the clocks with the date set way back in the past (by malice
or accident)?

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

[Shawn O. Pearce]

Alex Riesen <raa.lkml@gmail.com> wrote:
> Shawn O. Pearce, Wed, Aug 20, 2008 01:44:33 +0200:
> > 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.
> 
> Maybe I'm missing something, but aren't unsynchronized clocks a common
> thing in personal computing? Even maybe less common, but noticably
> frequent, the clocks with the date set way back in the past (by malice
> or accident)?

Oh, yea, clock skew is very common.  Clock skew by years is not
unexpected either.

We could pick any number for the limit, just so long as its so
large that the size of the reflog for it to be a valid @{nth}
request would be something like 1 TB, and thus be highly unlikely.

I was just trying to be cute by using the original commit timestamp
of Git itself.  Perhaps 12936648 (1TB / 83)?

-- 
Shawn.

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

[Alex Riesen]

Shawn O. Pearce, Wed, Aug 20, 2008 21:44:07 +0200:
> 
> We could pick any number for the limit, just so long as its so
> large that the size of the reflog for it to be a valid @{nth}
> request would be something like 1 TB, and thus be highly unlikely.
> 
> I was just trying to be cute by using the original commit timestamp
> of Git itself.  Perhaps 12936648 (1TB / 83)?

How about the maximum value the platform's size_t can handle?

Not because it is "highly unlikely", but because you and me frankly
have no idea exactly how unlikely for example a "12936648 terabytes" is?

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

[Shawn O. Pearce]

Alex Riesen <raa.lkml@gmail.com> wrote:
> Shawn O. Pearce, Wed, Aug 20, 2008 21:44:07 +0200:
> > 
> > We could pick any number for the limit, just so long as its so
> > large that the size of the reflog for it to be a valid @{nth}
> > request would be something like 1 TB, and thus be highly unlikely.
> > 
> > I was just trying to be cute by using the original commit timestamp
> > of Git itself.  Perhaps 12936648 (1TB / 83)?
> 
> How about the maximum value the platform's size_t can handle?

So on 64 bit platforms we need to wait for another 2.92277266
x10^10 years before we will ever see a seconds-since-epoch which
can't possibly be mistaken for a position in the relfog file?
 
> Not because it is "highly unlikely", but because you and me frankly
> have no idea exactly how unlikely for example a "12936648 terabytes" is?

I have half a brain.  Creating 12 million reflog entries would
typically require 12 million git-update-ref forks. Anyone who is
doing that many since reflog was introduced and has not yet truncated
their reflog _really_ should reconsider what they are using it for.

Evaluating foo@{12936648} will be _horribly_ expensive.  Anyone who
is waiting for that result and _cares_ about it would have already
started asking on the list for a reflog which is not based on a
flat file.  If they have already patched their Git to use something
else (e.g. gdbm) I have no pity for them when this changes/breaks
as they clearly have already patched their Git rather heavily.

-- 
Shawn.

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

[Alex Riesen]

Shawn O. Pearce, Wed, Aug 20, 2008 22:00:26 +0200:
> Alex Riesen <raa.lkml@gmail.com> wrote:
> > Shawn O. Pearce, Wed, Aug 20, 2008 21:44:07 +0200:
> > > 
> > > We could pick any number for the limit, just so long as its so
> > > large that the size of the reflog for it to be a valid @{nth}
> > > request would be something like 1 TB, and thus be highly unlikely.
> > > 
> > > I was just trying to be cute by using the original commit timestamp
> > > of Git itself.  Perhaps 12936648 (1TB / 83)?
> > 
> > How about the maximum value the platform's size_t can handle?
> 
> So on 64 bit platforms we need to wait for another 2.92277266
> x10^10 years before we will ever see a seconds-since-epoch which
> can't possibly be mistaken for a position in the relfog file?

It is just a timestamp. Can be set to anything.

> > Not because it is "highly unlikely", but because you and me frankly
> > have no idea exactly how unlikely for example a "12936648 terabytes" is?
> 
> I have half a brain.  Creating 12 million reflog entries would
> typically require 12 million git-update-ref forks. Anyone who is
> doing that many since reflog was introduced and has not yet truncated
> their reflog _really_ should reconsider what they are using it for.

Why? It may just as well work (unless there are some other, more
technical restrictions).

> Evaluating foo@{12936648} will be _horribly_ expensive.  Anyone who

Depends what you evaluate it on. 640kb was also more than enough for
anyone once.

> is waiting for that result and _cares_ about it would have already
> started asking on the list for a reflog which is not based on a
> flat file.  If they have already patched their Git to use something
> else (e.g. gdbm) I have no pity for them when this changes/breaks
> as they clearly have already patched their Git rather heavily.

Why should you _care_?

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

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> I was just trying to be cute by using the original commit timestamp
> of Git itself.  Perhaps 12936648 (1TB / 83)?

Well, reverse psychology did not quite work, I guess, so I'd ask more
directly.  Why not re-send with an update to the same 8-digit rule we use
elsewhere?

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

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > I was just trying to be cute by using the original commit timestamp
> > of Git itself.  Perhaps 12936648 (1TB / 83)?
> 
> Well, reverse psychology did not quite work, I guess, so I'd ask more
> directly.  Why not re-send with an update to the same 8-digit rule we use
> elsewhere?

--8<--
Make reflog query '@{1219188291}' act as '@{2008.8.19.16.24.51}'

As we support seconds-since-epoch in $GIT_COMMITTER_TIME we should
also support it in a reflog @{...} style notation.  We can easily
tell this part from @{nth} style notation by looking to see if the
value is unreasonably large for an @{nth} style notation.

The value 100000000 was chosen as it is already used by date.c to
disambiguate yyyymmdd format from a seconds-since-epoch time value.

A reflog with 100,000,000 record entries is also simply not valid.
Such a reflog would require at least 7.7 GB to store just the old
and new SHA-1 values.  So our randomly chosen upper limit for @{nth}
notation is "big enough".

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 sha1_name.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 4fb77f8..41b6809 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -349,7 +349,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 			else
 				nth = -1;
 		}
-		if (0 <= nth)
+		if (100000000 <= nth) {
+			at_time = nth;
+			nth = -1;
+		} else if (0 <= nth)
 			at_time = 0;
 		else {
 			char *tmp = xstrndup(str + at + 2, reflog_len);
-- 
1.6.0.112.g9c75


-- 
Shawn.