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

"Shawn O. Pearce" [off-list ref] 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?

Junio C Hamano [off-list ref] wrote:

"Shawn O. Pearce" [off-list ref] writes:

quoted

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