{"thread":{"id":"15099","subject":"[PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","startedAt":"2008-08-19T23:44:33Z","lastAt":"2008-08-21T15:40:44Z","messageCount":10,"participants":["Shawn O. Pearce","Junio C Hamano","Alex Riesen"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"87770","messageId":"20080819234433.GJ24212@spearce.org","threadId":"15099","inReplyTo":null,"subject":"[PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-19T23:44:33Z","receivedAt":"2008-08-19T23:44:33Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"As we support seconds-since-epoch in $GIT_COMMITTER_TIME we should\nalso support it in a reflog @{...} style notation. We can easily\ntell this apart from @{nth} style notation by looking to see if\nthe value is unreasonably large for an @{nth} style notation.\n\nThe value 1112911993 was chosen for the limit as it is the commit\ntimestamp for e83c516331 \"Initial revision of \"git\" ...\". Any\nreflogs in existance should contain timestamps dated later than\nthe date Linus first stored Git into itself, as reflogs came about\nquite a bit after that.\n\nAdditionally a reflog with 1,112,911,993 record entries is also\nsimply not valid. Such a reflog would require at least 87 TB to\nstore just the old and new SHA-1 values. So our randomly chosen\nupper limit for @{nth} notation is \"big enough\" that users will\nnot run into it by accident.\n\nSigned-off-by: Shawn O. Pearce \n---\n sha1_name.c | 5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 4fb77f8..e25f56a 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -349,7 +349,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \t\t\telse\n \t\t\t\tnth = -1;\n \t\t}\n-\t\tif (0 <= nth)\n+\t\tif (1112911993 <= nth) {\n+\t\t\tat_time = nth;\n+\t\t\tnth = -1;\n+\t\t} else if (0 <= nth)\n \t\t\tat_time = 0;\n \t\telse {\n \t\t\tchar *tmp = xstrndup(str + at + 2, reflog_len);\n-- \n1.6.0.96.g2fad1.dirty\n\n-- \nShawn.\n"},{"id":"87772","messageId":"7vskt0woat.fsf@gitster.siamese.dyndns.org","threadId":"15099","inReplyTo":"20080819234433.GJ24212@spearce.org","subject":"Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-19T23:57:46Z","receivedAt":"2008-08-19T23:57:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> The value 1112911993 was chosen for the limit as it is the commit\n> timestamp for e83c516331 \"Initial revision of \"git\" ...\". Any\n> reflogs in existance should contain timestamps dated later than\n> the date Linus first stored Git into itself, as reflogs came about\n> quite a bit after that.\n>\n> Additionally a reflog with 1,112,911,993 record entries is also\n> simply not valid. Such a reflog would require at least 87 TB to\n> store just the old and new SHA-1 values. So our randomly chosen\n> upper limit for @{nth} notation is \"big enough\" that users will\n> not run into it by accident.\n\nHmm, would we want to apply that logic to replace the magic \"8-digit\" rule\nin date.c::match_digit()?\n"},{"id":"87774","messageId":"20080820000306.GL24212@spearce.org","threadId":"15099","inReplyTo":"7vskt0woat.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-20T00:03:06Z","receivedAt":"2008-08-20T00:03:06Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > The value 1112911993 was chosen for the limit as it is the commit\n> > timestamp for e83c516331 \"Initial revision of \"git\" ...\". Any\n> > reflogs in existance should contain timestamps dated later than\n> > the date Linus first stored Git into itself, as reflogs came about\n> > quite a bit after that.\n> >\n> > Additionally a reflog with 1,112,911,993 record entries is also\n> > simply not valid. Such a reflog would require at least 87 TB to\n> > store just the old and new SHA-1 values. So our randomly chosen\n> > upper limit for @{nth} notation is \"big enough\" that users will\n> > not run into it by accident.\n> \n> Hmm, would we want to apply that logic to replace the magic \"8-digit\" rule\n> in date.c::match_digit()?\n\nNo. Isn't match_digit() in the code path used by GIT_COMMITTER_DATE?\nWe should handle dates as far back as Sat Mar 3 01:46:40 1973 as\nseconds-since-epoch to support conversion tools which bring in old\nhistory that predates Git's inception.\n\nIf anything the reflog code should change its test to be the same\n\"8-digit\" rule. A reflog of 100,000,000 entries requires at least\n7.9G, a threshold which isn't utterly insane (as it fits on a DVD-R)\nbut still is not really reasonable for current Git reflog.\n\n-- \nShawn.\n"},{"id":"87849","messageId":"20080820193557.GB16626@blimp.local","threadId":"15099","inReplyTo":"20080819234433.GJ24212@spearce.org","subject":"Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-20T19:35:57Z","receivedAt":"2008-08-20T19:35:57Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Shawn O. Pearce, Wed, Aug 20, 2008 01:44:33 +0200:\n> The value 1112911993 was chosen for the limit as it is the commit\n> timestamp for e83c516331 \"Initial revision of \"git\" ...\". Any\n> reflogs in existance should contain timestamps dated later than\n> the date Linus first stored Git into itself, as reflogs came about\n> quite a bit after that.\n\nMaybe I'm missing something, but aren't unsynchronized clocks a common\nthing in personal computing? Even maybe less common, but noticably\nfrequent, the clocks with the date set way back in the past (by malice\nor accident)?\n"},{"id":"87851","messageId":"20080820194407.GJ3483@spearce.org","threadId":"15099","inReplyTo":"20080820193557.GB16626@blimp.local","subject":"Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-20T19:44:07Z","receivedAt":"2008-08-20T19:44:07Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen wrote:\n> Shawn O. Pearce, Wed, Aug 20, 2008 01:44:33 +0200:\n> > The value 1112911993 was chosen for the limit as it is the commit\n> > timestamp for e83c516331 \"Initial revision of \"git\" ...\". Any\n> > reflogs in existance should contain timestamps dated later than\n> > the date Linus first stored Git into itself, as reflogs came about\n> > quite a bit after that.\n> \n> Maybe I'm missing something, but aren't unsynchronized clocks a common\n> thing in personal computing? Even maybe less common, but noticably\n> frequent, the clocks with the date set way back in the past (by malice\n> or accident)?\n\nOh, yea, clock skew is very common. Clock skew by years is not\nunexpected either.\n\nWe could pick any number for the limit, just so long as its so\nlarge that the size of the reflog for it to be a valid @{nth}\nrequest would be something like 1 TB, and thus be highly unlikely.\n\nI was just trying to be cute by using the original commit timestamp\nof Git itself. Perhaps 12936648 (1TB / 83)?\n\n-- \nShawn.\n"},{"id":"87855","messageId":"20080820195401.GD16626@blimp.local","threadId":"15099","inReplyTo":"20080820194407.GJ3483@spearce.org","subject":"Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-20T19:54:01Z","receivedAt":"2008-08-20T19:54:01Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Shawn O. Pearce, Wed, Aug 20, 2008 21:44:07 +0200:\n> \n> We could pick any number for the limit, just so long as its so\n> large that the size of the reflog for it to be a valid @{nth}\n> request would be something like 1 TB, and thus be highly unlikely.\n> \n> I was just trying to be cute by using the original commit timestamp\n> of Git itself. Perhaps 12936648 (1TB / 83)?\n\nHow about the maximum value the platform's size_t can handle?\n\nNot because it is \"highly unlikely\", but because you and me frankly\nhave no idea exactly how unlikely for example a \"12936648 terabytes\" is?\n"},{"id":"87857","messageId":"20080820200026.GK3483@spearce.org","threadId":"15099","inReplyTo":"20080820195401.GD16626@blimp.local","subject":"Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-20T20:00:26Z","receivedAt":"2008-08-20T20:00:26Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen wrote:\n> Shawn O. Pearce, Wed, Aug 20, 2008 21:44:07 +0200:\n> > \n> > We could pick any number for the limit, just so long as its so\n> > large that the size of the reflog for it to be a valid @{nth}\n> > request would be something like 1 TB, and thus be highly unlikely.\n> > \n> > I was just trying to be cute by using the original commit timestamp\n> > of Git itself. Perhaps 12936648 (1TB / 83)?\n> \n> How about the maximum value the platform's size_t can handle?\n\nSo on 64 bit platforms we need to wait for another 2.92277266\nx10^10 years before we will ever see a seconds-since-epoch which\ncan't possibly be mistaken for a position in the relfog file?\n \n> Not because it is \"highly unlikely\", but because you and me frankly\n> have no idea exactly how unlikely for example a \"12936648 terabytes\" is?\n\nI have half a brain. Creating 12 million reflog entries would\ntypically require 12 million git-update-ref forks. Anyone who is\ndoing that many since reflog was introduced and has not yet truncated\ntheir reflog _really_ should reconsider what they are using it for.\n\nEvaluating foo@{12936648} will be _horribly_ expensive. Anyone who\nis waiting for that result and _cares_ about it would have already\nstarted asking on the list for a reflog which is not based on a\nflat file. If they have already patched their Git to use something\nelse (e.g. gdbm) I have no pity for them when this changes/breaks\nas they clearly have already patched their Git rather heavily.\n\n-- \nShawn.\n"},{"id":"87860","messageId":"20080820200912.GG16626@blimp.local","threadId":"15099","inReplyTo":"20080820200026.GK3483@spearce.org","subject":"Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-20T20:09:12Z","receivedAt":"2008-08-20T20:09:12Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Shawn O. Pearce, Wed, Aug 20, 2008 22:00:26 +0200:\n> Alex Riesen wrote:\n> > Shawn O. Pearce, Wed, Aug 20, 2008 21:44:07 +0200:\n> > > \n> > > We could pick any number for the limit, just so long as its so\n> > > large that the size of the reflog for it to be a valid @{nth}\n> > > request would be something like 1 TB, and thus be highly unlikely.\n> > > \n> > > I was just trying to be cute by using the original commit timestamp\n> > > of Git itself. Perhaps 12936648 (1TB / 83)?\n> > \n> > How about the maximum value the platform's size_t can handle?\n> \n> So on 64 bit platforms we need to wait for another 2.92277266\n> x10^10 years before we will ever see a seconds-since-epoch which\n> can't possibly be mistaken for a position in the relfog file?\n\nIt is just a timestamp. Can be set to anything.\n\n> > Not because it is \"highly unlikely\", but because you and me frankly\n> > have no idea exactly how unlikely for example a \"12936648 terabytes\" is?\n> \n> I have half a brain. Creating 12 million reflog entries would\n> typically require 12 million git-update-ref forks. Anyone who is\n> doing that many since reflog was introduced and has not yet truncated\n> their reflog _really_ should reconsider what they are using it for.\n\nWhy? It may just as well work (unless there are some other, more\ntechnical restrictions).\n\n> Evaluating foo@{12936648} will be _horribly_ expensive. Anyone who\n\nDepends what you evaluate it on. 640kb was also more than enough for\nanyone once.\n\n> is waiting for that result and _cares_ about it would have already\n> started asking on the list for a reflog which is not based on a\n> flat file. If they have already patched their Git to use something\n> else (e.g. gdbm) I have no pity for them when this changes/breaks\n> as they clearly have already patched their Git rather heavily.\n\nWhy should you _care_?\n"},{"id":"87895","messageId":"7vhc9fnxa1.fsf@gitster.siamese.dyndns.org","threadId":"15099","inReplyTo":"20080820194407.GJ3483@spearce.org","subject":"Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-20T22:20:54Z","receivedAt":"2008-08-20T22:20:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> I was just trying to be cute by using the original commit timestamp\n> of Git itself. Perhaps 12936648 (1TB / 83)?\n\nWell, reverse psychology did not quite work, I guess, so I'd ask more\ndirectly. Why not re-send with an update to the same 8-digit rule we use\nelsewhere?\n"},{"id":"88000","messageId":"20080821154044.GU3483@spearce.org","threadId":"15099","inReplyTo":"7vhc9fnxa1.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-21T15:40:44Z","receivedAt":"2008-08-21T15:40:44Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > I was just trying to be cute by using the original commit timestamp\n> > of Git itself. Perhaps 12936648 (1TB / 83)?\n> \n> Well, reverse psychology did not quite work, I guess, so I'd ask more\n> directly. Why not re-send with an update to the same 8-digit rule we use\n> elsewhere?\n\n--8<--\nMake reflog query '@{1219188291}' act as '@{2008.8.19.16.24.51}'\n\nAs we support seconds-since-epoch in $GIT_COMMITTER_TIME we should\nalso support it in a reflog @{...} style notation. We can easily\ntell this part from @{nth} style notation by looking to see if the\nvalue is unreasonably large for an @{nth} style notation.\n\nThe value 100000000 was chosen as it is already used by date.c to\ndisambiguate yyyymmdd format from a seconds-since-epoch time value.\n\nA reflog with 100,000,000 record entries is also simply not valid.\nSuch a reflog would require at least 7.7 GB to store just the old\nand new SHA-1 values. So our randomly chosen upper limit for @{nth}\nnotation is \"big enough\".\n\nSigned-off-by: Shawn O. Pearce \n---\n sha1_name.c | 5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 4fb77f8..41b6809 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -349,7 +349,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \t\t\telse\n \t\t\t\tnth = -1;\n \t\t}\n-\t\tif (0 <= nth)\n+\t\tif (100000000 <= nth) {\n+\t\t\tat_time = nth;\n+\t\t\tnth = -1;\n+\t\t} else if (0 <= nth)\n \t\t\tat_time = 0;\n \t\telse {\n \t\t\tchar *tmp = xstrndup(str + at + 2, reflog_len);\n-- \n1.6.0.112.g9c75\n\n\n-- \nShawn.\n"}]}