{"thread":{"id":"12409","subject":"ambiguous git-log date and timestamp syntax","startedAt":"2008-03-01T16:15:56Z","lastAt":"2008-03-02T14:40:52Z","messageCount":9,"participants":["Rhodes, Kate","Jakub Narebski","Linus Torvalds","Johannes Schindelin","Florian Weimer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"70538","messageId":"715587AA-D485-4B31-A786-D26334506007@gmail.com","threadId":"12409","inReplyTo":null,"subject":"ambiguous git-log date and timestamp syntax","fromName":"Rhodes, Kate","fromEmail":"masukomi@gmail.com","sentAt":"2008-03-01T16:15:56Z","receivedAt":"2008-03-01T16:15:56Z","isPatch":false,"sender":{"key":"masukomi@gmail.com","avatar":null},"body":"The docs are a little vague on exactly what your options are when  \nspecifying dates. If someone can provide me some details on this i'll  \nmake a patch for the docs.\n\n--since=date, --after=date\n\tShow commits more recent than a specific date.\n--until=date, --before=date\n\tShow commits older than a specific date.\n--max-age=timestamp, --min-age=timestamp\n\tLimit the commits output to specified time range.\n\n From what i can tell it seems that dates can be specified relatively,  \ne.g. \"2 hours ago\", or with any ISO 8601 or RFC 2822 date syntax. Is  \nthis correct, and are there any docs on specifying relative dates?\n\nI can't find any details on what the \"timestamp\" format should be. Can  \nsomeone point me in the right direction?\n\n-Kate == masukomi\n"},{"id":"70542","messageId":"m3d4qejroy.fsf@localhost.localdomain","threadId":"12409","inReplyTo":"715587AA-D485-4B31-A786-D26334506007@gmail.com","subject":"Re: ambiguous git-log date and timestamp syntax","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-01T17:10:39Z","receivedAt":"2008-03-01T17:10:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Rhodes, Kate\" <masukomi@gmail.com> writes:\n\n> The docs are a little vague on exactly what your options are when\n> specifying dates. If someone can provide me some details on this I'll\n> make a patch for the docs.\n> \n> --since=date, --after=date\n> \tShow commits more recent than a specific date.\n> --until=date, --before=date\n> \tShow commits older than a specific date.\n\nThose are porcelain (meant for user) options.\n\n> --max-age=timestamp, --min-age=timestamp\n> \tLimit the commits output to specified time range.\n\nThose are plumbing (meant for scripts) options.\n\nFor example git-rev-parse translates --since into --max-age, etc.\n\n> From what I can tell it seems that dates can be specified relatively,\n> e.g. \"2 hours ago\", or with any ISO 8601 or RFC 2822 date syntax. Is\n> this correct, and are there any docs on specifying relative dates?\n\nI don't know why git doesn't use getdate_r for this, instead rolling\nout its own date parsing routines: approxidate*, parse_date. From what\nI remember it should accept any date \"date\" (from coreutils) accepts,\nbut it does (from comments) for date to be in \"C\" locale.\n\nSo I'm sorry, but I cannot help you here...\n\n> I can't find any details on what the \"timestamp\" format should be. Can\n> someone point me in the right direction?\n\nTimestamp is Unix date (epoch), i.e. number of seconds since\n1970-01-01 00:00:00 UTC, the format git uses for dates in commit and\ntag objects.\n \n> -Kate == masukomi\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"70562","messageId":"alpine.LFD.1.00.0803011010480.17889@woody.linux-foundation.org","threadId":"12409","inReplyTo":"m3d4qejroy.fsf@localhost.localdomain","subject":"Re: ambiguous git-log date and timestamp syntax","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-01T21:46:39Z","receivedAt":"2008-03-01T21:46:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 1 Mar 2008, Jakub Narebski wrote:\n> > \n> > From what I can tell it seems that dates can be specified relatively,\n> > e.g. \"2 hours ago\", or with any ISO 8601 or RFC 2822 date syntax. Is\n> > this correct, and are there any docs on specifying relative dates?\n> \n> I don't know why git doesn't use getdate_r for this, instead rolling\n> out its own date parsing routines: approxidate*, parse_date. From what\n> I remember it should accept any date \"date\" (from coreutils) accepts,\n> but it does (from comments) for date to be in \"C\" locale.\n\nstrptime() and getdate() are totally unusable for any real date parsing \nwhere you don't already know the exact format(s) of the string. And \nneither of them can do any of the useful things that approxidate() does, \nie handle strings like \"two months ago\".\n\nSo yes, we do our own date parsing, where the \"exact\" format is the Unix \nepoch timestamp (potentially together with explicit TZ information), but \nwe try to parse a wide variety of user-supplied strings that match any of \nthe standard formats (and do that loosely, so that when emails etc \ninvariably get things wrong and don't actually follow rfc2822 exactly, for \nexample, it still tries to make sense of it).\n\nAnd then when the more-or-less exact format check fails, we fall back on \nthe really approximate guessing, which accepts any random input and turns \nit into a date (ie \"two days ago at noon\" will give you *some* results, \nbut whether they are the results you meant or not is debatable: I think \n\"noon\" will always round down to the previous noon, for example, so it \nmigth be closer to three days ago).\n\nSo the \"timestamp\" is a pure integer (seconds since epoch), and in most \nother places git will accept dates that are more or less any half-way sane \nformat for interchange.\n\nOf course, the only reason for --max-age=timestamp, --min-age=timestamp \nexisting int he first place is that *historically* normal git commands \ncould only parse the strict \"seconds since epoch\", and we had that magical \nspecial \"git rev-parse\" function that turned the human-readable date into \nan exact timestamp.\n\nYou can still see it:\n\n\t[torvalds@woody git]$ git-rev-parse  --until=\"2.hours.ago\"\n\noutputs\n\n\t--min-age=1204387613\n\nwhich is the machine-readable format, but that's purely historical, since \nnow all commands that take that machine-readable format also take the \nhuman format directly, so it might make more sense to just not even \ndocument that \"--[min|max]-age=timestamp\" thing.\n\n\t\t\tLinus\n"},{"id":"70564","messageId":"200803012326.05698.jnareb@gmail.com","threadId":"12409","inReplyTo":"alpine.LFD.1.00.0803011010480.17889@woody.linux-foundation.org","subject":"Re: ambiguous git-log date and timestamp syntax","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-01T22:26:04Z","receivedAt":"2008-03-01T22:26:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 1 Mar 2008, Linus Torvalds wrote:\n> On Sat, 1 Mar 2008, Jakub Narebski wrote:\n> > > \n> > > From what I can tell it seems that dates can be specified relatively,\n> > > e.g. \"2 hours ago\", or with any ISO 8601 or RFC 2822 date syntax. Is\n> > > this correct, and are there any docs on specifying relative dates?\n> > \n> > I don't know why git doesn't use getdate_r for this, instead rolling\n> > out its own date parsing routines: approxidate*, parse_date. From what\n> > I remember it should accept any date \"date\" (from coreutils) accepts,\n> > but it does (from comments) for date to be in \"C\" locale.\n> \n> strptime() and getdate() are totally unusable for any real date parsing \n> where you don't already know the exact format(s) of the string. And \n> neither of them can do any of the useful things that approxidate() does, \n> ie handle strings like \"two months ago\".\n> \n> So yes, we do our own date parsing, where the \"exact\" format is the Unix \n> epoch timestamp (potentially together with explicit TZ information), but \n> we try to parse a wide variety of user-supplied strings that match any of \n> the standard formats (and do that loosely, so that when emails etc \n> invariably get things wrong and don't actually follow rfc2822 exactly, for \n> example, it still tries to make sense of it).\n\nI wonder how it compares with GNU date (from GNU Corutils) inexact date\nparsing (and why we couldn't lift the code from GNU date)... I guess that\nmain goal was to parse correctly \"mail\" dates, first.\n\n\nBTW. Git has few other such \"reimplementing the wheel\" things, like strbuf,\nor ALLOC_GROW, or it's own parseopt. I guess main reasons are to avoid\nadding yet another dependency, and that existing solutions doesn't fill\nall git needs.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"70572","messageId":"alpine.LSU.1.00.0803020240390.22527@racer.site","threadId":"12409","inReplyTo":"200803012326.05698.jnareb@gmail.com","subject":"Re: ambiguous git-log date and timestamp syntax","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-02T02:44:35Z","receivedAt":"2008-03-02T02:44:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 1 Mar 2008, Jakub Narebski wrote:\n\n> BTW. Git has few other such \"reimplementing the wheel\" things, like \n> strbuf, or ALLOC_GROW, or it's own parseopt. I guess main reasons are to \n> avoid adding yet another dependency, and that existing solutions doesn't \n> fill all git needs.\n\nOr that the existing wheels are quadratic wheels, and flat.\n\nJust look at our own parse-options.[ch].  It is _still_ smaller and less \ndifficult to read than GNU getopt.  Yet, it is also much more powerful and \neasier to use.\n\nLikewise, strbuf compares to Bstring, for example (although you might say \nthat Bstring is more powerful, but it comes at a price: it clutters the \nnamespace, and is not as performant as strbuf).\n\nALLOC_GROW() is so small as to not merit any third-party dependency.  \n\nAlso, I'd like to caution that depending on 3rd-party libraries is not \nalways easy: just think about how much pain we suffer from the \never-changing asciidoc package, and the problems wit docbook xsl.\n\nCiao,\nDscho\n\n"},{"id":"70590","messageId":"87skz91u0p.fsf@mid.deneb.enyo.de","threadId":"12409","inReplyTo":"200803012326.05698.jnareb@gmail.com","subject":"Re: ambiguous git-log date and timestamp syntax","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2008-03-02T07:09:58Z","receivedAt":"2008-03-02T07:09:58Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Jakub Narebski:\n\n> I wonder how it compares with GNU date (from GNU Corutils) inexact date\n> parsing (and why we couldn't lift the code from GNU date)...\n\nI think the licenses are incompatible, you can't link that code to\nOpenSSL.\n"},{"id":"70610","messageId":"200803021040.55252.jnareb@gmail.com","threadId":"12409","inReplyTo":"alpine.LSU.1.00.0803020240390.22527@racer.site","subject":"Re: ambiguous git-log date and timestamp syntax","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-02T09:40:54Z","receivedAt":"2008-03-02T09:40:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 2 Mar 2008, Johannes Schindelin wrote:\n> On Sat, 1 Mar 2008, Jakub Narebski wrote:\n> \n>> BTW. Git has few other such \"reimplementing the wheel\" things, like \n>> strbuf, or ALLOC_GROW, or it's own parseopt. I guess main reasons are to \n>> avoid adding yet another dependency, and that existing solutions doesn't \n>> fill all git needs.\n> \n> Or that the existing wheels are quadratic wheels, and flat.\n\nThat's what I meant by \"existing solutions don't fill all git needs\".\n\n> Just look at our own parse-options.[ch].  It is _still_ smaller and less \n> difficult to read than GNU getopt.  Yet, it is also much more powerful and \n> easier to use.\n\nI meant here not only 'getopt', but also 'argp' (from libc), or 'popt'\nlibrary (used by rpm).\n\n> Likewise, strbuf compares to Bstring, for example (although you might say \n> that Bstring is more powerful, but it comes at a price: it clutters the \n> namespace, and is not as performant as strbuf).\n\nI vaguely recall something of discussion about this.\n\n> ALLOC_GROW() is so small as to not merit any third-party dependency.  \n\nTrue.\n\n> Also, I'd like to caution that depending on 3rd-party libraries is not \n> always easy: just think about how much pain we suffer from the \n> ever-changing asciidoc package, and the problems wit docbook xsl.\n\nI was rather thinking about something like git \"dependency\" on libXdiff,\nnamely having it embedded in git sources, perhaps as submodule, with git\nspecific improvements / changes / simplifications.\n\n\nI wonder if it would be worthwhile to extract all those useful codelets\n(mini libraries) like approxidate, strbuf, parseopt, ALLOC_GROW, \nlist utils, etc. into separate micro-projects, to be able to be used\nby other projects, for *them* not to have to reimplement the wheel.\n\nJust a thought...\n-- \nJakub Narebski\nPoland\n"},{"id":"70636","messageId":"1204467095-24701-1-git-send-email-jnareb@gmail.com","threadId":"12409","inReplyTo":"715587AA-D485-4B31-A786-D26334506007@gmail.com","subject":"[PATCH] Documentation: Remove --{min,max}-age option from git-log(1)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-02T14:11:35Z","receivedAt":"2008-03-02T14:11:35Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"The --max-age=<timestamp> and --min-age=<timestamp> are now shown only\nin the git-rev-list manpage (plumbing).\n\nSigned-off-by: Jakub Narebski <jnareb@gmail.com>\n---\n Documentation/rev-list-options.txt |    2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt\nindex a8138e2..c62ff49 100644\n--- a/Documentation/rev-list-options.txt\n+++ b/Documentation/rev-list-options.txt\n@@ -130,9 +130,11 @@ limiting may be applied.\n \n \tShow commits older than a specific date.\n \n+ifdef::git-rev-list[]\n --max-age='timestamp', --min-age='timestamp'::\n \n \tLimit the commits output to specified time range.\n+endif::git-rev-list[]\n \n --author='pattern', --committer='pattern'::\n \n-- \n1.5.4.2\n\n"},{"id":"70639","messageId":"alpine.LSU.1.00.0803021438010.22527@racer.site","threadId":"12409","inReplyTo":"200803021040.55252.jnareb@gmail.com","subject":"Re: ambiguous git-log date and timestamp syntax","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-02T14:40:52Z","receivedAt":"2008-03-02T14:40:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 2 Mar 2008, Jakub Narebski wrote:\n\n> I wonder if it would be worthwhile to extract all those useful codelets \n> (mini libraries) like approxidate, strbuf, parseopt, ALLOC_GROW, list \n> utils, etc. into separate micro-projects, to be able to be used by other \n> projects, for *them* not to have to reimplement the wheel.\n\nActually, something like this happens in git-cheetah ATM, where I would \nlike to use parts of libgit.a to call programs.\n\nBut then, I see the responsibility of separating out parts of libgit.a by \nthose who want to use it, not by the git crowd.\n\nCiao,\nDscho\n\n"}]}