{"thread":{"id":"17925","subject":"[PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","startedAt":"2009-02-20T21:23:54Z","lastAt":"2009-02-24T07:07:22Z","messageCount":15,"participants":["eletuchy@gmail.com","Linus Torvalds","Eugene Letuchy","Junio C Hamano","Jeff King","Marius Storm-Olsen"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"105656","messageId":"1235165034-20299-1-git-send-email-eletuchy@gmail.com","threadId":"17925","inReplyTo":null,"subject":"[PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"","fromEmail":"eletuchy@gmail.com","sentAt":"2009-02-20T21:23:54Z","receivedAt":"2009-02-20T21:23:54Z","isPatch":true,"sender":{"key":"eletuchy@gmail.com","avatar":null},"body":"From: Eugene Letuchy \n\nIn the context of sizing the git blame time column, it doesn't make a\nlot of sense to see \"12 months ago\" next to an exact timestamp +\ntimezone for something 13 months ago. This commit makes commits older\nthan 12 months display the date only, not the time.\n\nSigned-off-by: Eugene Letuchy \n---\n builtin-blame.c | 5 ++---\n date.c | 4 +++-\n 2 files changed, 5 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-blame.c b/builtin-blame.c\nindex aa5c66c..48cedfd 100644\n--- a/builtin-blame.c\n+++ b/builtin-blame.c\n@@ -2286,9 +2286,8 @@ parse_done:\n \t\tblame_date_width = sizeof(\"2006-10-19\");\n \t\tbreak;\n \tcase DATE_RELATIVE:\n-\t\t/* unfortunately \"normal\" is the fallback for \"relative\" */\n-\t\t/* blame_date_width = sizeof(\"14 minutes ago\"); */\n-\t\t/* break; */\n+\t\tblame_date_width = sizeof(\"14 minutes ago\");\n+\t\tbreak;\n \tcase DATE_LOCAL:\n \tcase DATE_NORMAL:\n \t\tblame_date_width = sizeof(\"Thu Oct 19 16:00:04 2006 -0700\");\ndiff --git a/date.c b/date.c\nindex 950b88f..edb2078 100644\n--- a/date.c\n+++ b/date.c\n@@ -128,7 +128,9 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)\n \t\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu months ago\", (diff + 15) / 30);\n \t\t\treturn timebuf;\n \t\t}\n-\t\t/* Else fall back on absolute format.. */\n+\n+\t\t/* Else fall back to the short format */\n+\t\tmode = DATE_SHORT;\n \t}\n \n \tif (mode == DATE_LOCAL)\n-- \n1.6.2.rc1.14.g07c3.dirty\n"},{"id":"105660","messageId":"alpine.LFD.2.00.0902201409230.21686@localhost.localdomain","threadId":"17925","inReplyTo":"1235165034-20299-1-git-send-email-eletuchy@gmail.com","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-02-20T22:15:22Z","receivedAt":"2009-02-20T22:15:22Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nSubject: Support 'raw' date format\n\nTalking about --date, one thing I wanted for the 1234567890 date was to \nget things in the raw format. Sure, you get them with --pretty=raw, but it \nfelt a bit sad that you couldn't just ask for the date in raw format.\n\nSo here's a throw-away patch (meaning: I won't be re-sending it, because I \nreally don't think it's a big deal) to add \"--date=raw\". It just prints \nout the internal raw git format - seconds since epoch plus timezone (put \nanother way: 'date +\"%s %z\"' format)\n\nSigned-off-by: Linus Torvalds \n---\n\nNot a whole lot of testing. But \n\n\tgit show --date=raw v2.6.29-rc5\n\nworks correctly.\n\n Documentation/rev-list-options.txt | 4 +++-\n cache.h | 3 ++-\n date.c | 7 +++++++\n 3 files changed, 12 insertions(+), 2 deletions(-)\n\ndiff --git i/Documentation/rev-list-options.txt w/Documentation/rev-list-options.txt\nindex b9f6e4d..5076322 100644\n--- i/Documentation/rev-list-options.txt\n+++ w/Documentation/rev-list-options.txt\n@@ -13,7 +13,7 @@ include::pretty-options.txt[]\n \n \tSynonym for `--date=relative`.\n \n---date={relative,local,default,iso,rfc,short}::\n+--date={relative,local,default,iso,rfc,short,raw}::\n \n \tOnly takes effect for dates shown in human-readable format, such\n \tas when using \"--pretty\". `log.date` config variable sets a default\n@@ -31,6 +31,8 @@ format, often found in E-mail messages.\n +\n `--date=short` shows only date but not time, in `YYYY-MM-DD` format.\n +\n+`--date=raw` shows the date in the internal raw git format `%s %z` format.\n++\n `--date=default` shows timestamps in the original timezone\n (either committer's or author's).\n \ndiff --git i/cache.h w/cache.h\nindex 21a6310..189151d 100644\n--- i/cache.h\n+++ w/cache.h\n@@ -696,7 +696,8 @@ enum date_mode {\n \tDATE_SHORT,\n \tDATE_LOCAL,\n \tDATE_ISO8601,\n-\tDATE_RFC2822\n+\tDATE_RFC2822,\n+\tDATE_RAW\n };\n \n const char *show_date(unsigned long time, int timezone, enum date_mode mode);\ndiff --git i/date.c w/date.c\nindex 950b88f..d75dff4 100644\n--- i/date.c\n+++ w/date.c\n@@ -89,6 +89,11 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)\n \tstruct tm *tm;\n \tstatic char timebuf[200];\n \n+\tif (mode == DATE_RAW) {\n+\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu %+05d\", time, tz);\n+\t\treturn timebuf;\n+\t}\n+\n \tif (mode == DATE_RELATIVE) {\n \t\tunsigned long diff;\n \t\tstruct timeval now;\n@@ -615,6 +620,8 @@ enum date_mode parse_date_format(const char *format)\n \t\treturn DATE_LOCAL;\n \telse if (!strcmp(format, \"default\"))\n \t\treturn DATE_NORMAL;\n+\telse if (!strcmp(format, \"raw\"))\n+\t\treturn DATE_RAW;\n \telse\n \t\tdie(\"unknown date format %s\", format);\n }\n"},{"id":"105662","messageId":"fbb390660902201447q560b94f8p969889da5e2686f4@mail.gmail.com","threadId":"17925","inReplyTo":"alpine.LFD.2.00.0902201409230.21686@localhost.localdomain","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Eugene Letuchy","fromEmail":"eletuchy@gmail.com","sentAt":"2009-02-20T22:47:11Z","receivedAt":"2009-02-20T22:47:11Z","isPatch":true,"sender":{"key":"eletuchy@gmail.com","avatar":null},"body":"Cool. I think git blame would need to be tweaked a bit after my patch\n(at least documentation wise), since it already has a \"raw timestamp\"\noption (-t).\n\nOn Fri, Feb 20, 2009 at 2:15 PM, Linus Torvalds\n wrote:\n>\n> Subject: Support 'raw' date format\n>\n> Talking about --date, one thing I wanted for the 1234567890 date was to\n> get things in the raw format. Sure, you get them with --pretty=raw, but it\n> felt a bit sad that you couldn't just ask for the date in raw format.\n>\n> So here's a throw-away patch (meaning: I won't be re-sending it, because I\n> really don't think it's a big deal) to add \"--date=raw\". It just prints\n> out the internal raw git format - seconds since epoch plus timezone (put\n> another way: 'date +\"%s %z\"' format)\n>\n> Signed-off-by: Linus Torvalds \n> ---\n>\n> Not a whole lot of testing. But\n>\n> git show --date=raw v2.6.29-rc5\n>\n> works correctly.\n>\n> Documentation/rev-list-options.txt | 4 +++-\n> cache.h | 3 ++-\n> date.c | 7 +++++++\n> 3 files changed, 12 insertions(+), 2 deletions(-)\n>\n> diff --git i/Documentation/rev-list-options.txt w/Documentation/rev-list-options.txt\n> index b9f6e4d..5076322 100644\n> --- i/Documentation/rev-list-options.txt\n> +++ w/Documentation/rev-list-options.txt\n> @@ -13,7 +13,7 @@ include::pretty-options.txt[]\n>\n> Synonym for `--date=relative`.\n>\n> ---date={relative,local,default,iso,rfc,short}::\n> +--date={relative,local,default,iso,rfc,short,raw}::\n>\n> Only takes effect for dates shown in human-readable format, such\n> as when using \"--pretty\". `log.date` config variable sets a default\n> @@ -31,6 +31,8 @@ format, often found in E-mail messages.\n> +\n> `--date=short` shows only date but not time, in `YYYY-MM-DD` format.\n> +\n> +`--date=raw` shows the date in the internal raw git format `%s %z` format.\n> ++\n> `--date=default` shows timestamps in the original timezone\n> (either committer's or author's).\n>\n> diff --git i/cache.h w/cache.h\n> index 21a6310..189151d 100644\n> --- i/cache.h\n> +++ w/cache.h\n> @@ -696,7 +696,8 @@ enum date_mode {\n> DATE_SHORT,\n> DATE_LOCAL,\n> DATE_ISO8601,\n> - DATE_RFC2822\n> + DATE_RFC2822,\n> + DATE_RAW\n> };\n>\n> const char *show_date(unsigned long time, int timezone, enum date_mode mode);\n> diff --git i/date.c w/date.c\n> index 950b88f..d75dff4 100644\n> --- i/date.c\n> +++ w/date.c\n> @@ -89,6 +89,11 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)\n> struct tm *tm;\n> static char timebuf[200];\n>\n> + if (mode == DATE_RAW) {\n> + snprintf(timebuf, sizeof(timebuf), \"%lu %+05d\", time, tz);\n> + return timebuf;\n> + }\n> +\n> if (mode == DATE_RELATIVE) {\n> unsigned long diff;\n> struct timeval now;\n> @@ -615,6 +620,8 @@ enum date_mode parse_date_format(const char *format)\n> return DATE_LOCAL;\n> else if (!strcmp(format, \"default\"))\n> return DATE_NORMAL;\n> + else if (!strcmp(format, \"raw\"))\n> + return DATE_RAW;\n> else\n> die(\"unknown date format %s\", format);\n> }\n>\n\n\n\n-- \nEugene\n"},{"id":"105691","messageId":"7vab8gs5m7.fsf@gitster.siamese.dyndns.org","threadId":"17925","inReplyTo":"alpine.LFD.2.00.0902201409230.21686@localhost.localdomain","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-21T05:48:00Z","receivedAt":"2009-02-21T05:48:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> So here's a throw-away patch (meaning: I won't be re-sending it, because I \n> really don't think it's a big deal) to add \"--date=raw\". It just prints \n> out the internal raw git format - seconds since epoch plus timezone (put \n> another way: 'date +\"%s %z\"' format)\n\nHeh, who can discard a patch *WITH DOCUMENTATION* from you ;-)\n\nThanks.\n"},{"id":"105829","messageId":"20090222230620.GB19011@coredump.intra.peff.net","threadId":"17925","inReplyTo":"1235165034-20299-1-git-send-email-eletuchy@gmail.com","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-22T23:06:20Z","receivedAt":"2009-02-22T23:06:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2009 at 01:23:54PM -0800, eletuchy@gmail.com wrote:\n\n> From: Eugene Letuchy \n> \n> In the context of sizing the git blame time column, it doesn't make a\n> lot of sense to see \"12 months ago\" next to an exact timestamp +\n> timezone for something 13 months ago. This commit makes commits older\n> than 12 months display the date only, not the time.\n\nI think this is an improvement, though I was thinking of taking it a\nstep further:\n\ndiff --git a/date.c b/date.c\nindex d75dff4..6dbb8e8 100644\n--- a/date.c\n+++ b/date.c\n@@ -128,12 +128,14 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)\n \t\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu weeks ago\", (diff + 3) / 7);\n \t\t\treturn timebuf;\n \t\t}\n-\t\t/* Say months for the past 12 months or so */\n-\t\tif (diff < 360) {\n+\t\t/* Say months for the past 24 months or so */\n+\t\tif (diff < 720) {\n \t\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu months ago\", (diff + 15) / 30);\n \t\t\treturn timebuf;\n \t\t}\n-\t\t/* Else fall back on absolute format.. */\n+\t\t/* Otherwise, years. Centuries is probably overkill. */\n+\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu years ago\", (diff + 183) / 365);\n+\t\treturn timebuf;\n \t}\n \n \tif (mode == DATE_LOCAL)\n\n\nbut maybe other people actually like seeing the absolute time. I've\nalways found it jarring when reading relative times (but part of that\n_was_ because it was so long and exact).\n\n-Peff\n"},{"id":"105833","messageId":"7v7i3ix6yi.fsf@gitster.siamese.dyndns.org","threadId":"17925","inReplyTo":"20090222230620.GB19011@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-23T01:44:37Z","receivedAt":"2009-02-23T01:44:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Feb 20, 2009 at 01:23:54PM -0800, eletuchy@gmail.com wrote:\n>\n>> From: Eugene Letuchy \n>> \n>> In the context of sizing the git blame time column, it doesn't make a\n>> lot of sense to see \"12 months ago\" next to an exact timestamp +\n>> timezone for something 13 months ago. This commit makes commits older\n>> than 12 months display the date only, not the time.\n>\n> I think this is an improvement, though I was thinking of taking it a\n> step further:\n> ...\n> +\t\t/* Otherwise, years. Centuries is probably overkill. */\n> +\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu years ago\", (diff + 183) / 365);\n> +\t\treturn timebuf;\n> \t}\n> \n> \tif (mode == DATE_LOCAL)\n>\n>\n> but maybe other people actually like seeing the absolute time. I've\n> always found it jarring when reading relative times (but part of that\n> _was_ because it was so long and exact).\n\nI agree this is an improvement. It irritated me, too. And I do not think\nthis change falls into the category of bad backward incompatibility.\n\nI was hoping somebody would do a \"N years M months\", though.\n"},{"id":"105838","messageId":"20090223031631.GC22348@coredump.intra.peff.net","threadId":"17925","inReplyTo":"7v7i3ix6yi.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-23T03:16:31Z","receivedAt":"2009-02-23T03:16:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 22, 2009 at 05:44:37PM -0800, Junio C Hamano wrote:\n\n> > +\t\t/* Otherwise, years. Centuries is probably overkill. */\n> > +\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu years ago\", (diff + 183) / 365);\n> > +\t\treturn timebuf;\n> \n> I agree this is an improvement. It irritated me, too. And I do not think\n> this change falls into the category of bad backward incompatibility.\n> \n> I was hoping somebody would do a \"N years M months\", though.\n\nI thought about that, but I wanted to keep the maximum size down for\ncolumn output (like in git-blame). Which is why I bumped the \"use\nmonths\" limit to 24 months instead of 12.\n\nAnd that limit can also be tweaked. Surely at some point there is a\nrange where you no longer care about the months and \"N years\" has high\nenough resolution. But there is also a point where \"N months\" gets\ncumbersome (75 months is a more annoying than \"around 6 years\"). The\nquestion is whether we reach the \"cumbersome\" point before we reach the\n\"don't care about months\" point.\n\nAnother option would to give higher resolution in number of years, like\n\"3.5 years\" or even \"3.1 years\".\n\n-Peff\n"},{"id":"105881","messageId":"49A2599E.2030406@trolltech.com","threadId":"17925","inReplyTo":"20090223031631.GC22348@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2009-02-23T08:09:02Z","receivedAt":"2009-02-23T08:09:02Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Jeff King said the following on 23.02.2009 04:16:\n> On Sun, Feb 22, 2009 at 05:44:37PM -0800, Junio C Hamano wrote:\n>>> +\t\t/* Otherwise, years. Centuries is probably overkill. */\n>>> +\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu years ago\", (diff + 183) / 365);\n>>> +\t\treturn timebuf;\n>> I agree this is an improvement. It irritated me, too. And I do\n>> not think this change falls into the category of bad backward\n>> incompatibility.\n>> \n>> I was hoping somebody would do a \"N years M months\", though.\n> \n> I thought about that, but I wanted to keep the maximum size down\n> for column output (like in git-blame). Which is why I bumped the\n> \"use months\" limit to 24 months instead of 12.\n> \n> And that limit can also be tweaked. Surely at some point there is\n> a range where you no longer care about the months and \"N years\" has\n> high enough resolution. But there is also a point where \"N months\"\n> gets cumbersome (75 months is a more annoying than \"around 6\n> years\"). The question is whether we reach the \"cumbersome\" point\n> before we reach the \"don't care about months\" point.\n> \n> Another option would to give higher resolution in number of years,\n> like \"3.5 years\" or even \"3.1 years\".\n\nAnd using shorter names for the units would be a no-go?\n\n \"3y 2m ago\" <--\n \"3 years ago\"\n \"3 months ago\"\n \"3 weeks ago\"\n \"3 days ago\"\n \"3 hours ago\"\n \"3 mins ago\" <--\n \"3 secs ago\" <--\n\n-- \n.marius [@trolltech.com]\n'if you know what you're doing, it's not research'\n\n"},{"id":"105916","messageId":"7v8wnxun8e.fsf@gitster.siamese.dyndns.org","threadId":"17925","inReplyTo":"20090223031631.GC22348@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-23T16:33:37Z","receivedAt":"2009-02-23T16:33:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I thought about that, but I wanted to keep the maximum size down for\n> column output (like in git-blame). Which is why I bumped the \"use\n> months\" limit to 24 months instead of 12.\n>\n> And that limit can also be tweaked. Surely at some point there is a\n> range where you no longer care about the months and \"N years\" has high\n> enough resolution. But there is also a point where \"N months\" gets\n> cumbersome (75 months is a more annoying than \"around 6 years\"). The\n> question is whether we reach the \"cumbersome\" point before we reach the\n> \"don't care about months\" point.\n\nYes, \"75 months\" is unacceptable. I suspect people's mind would not work\nwell with anything larger than 60 months. I've actually thought about\n\"don't care about months\" point, but 12 months is a long time. You\ncertainly remember there still was a noticeable maturity difference\nbetween classmates who were born in the earliest months of the school year\nand in the last months before graduating grade school. Perhaps after 20\nyears.\n\n> Another option would to give higher resolution in number of years, like\n> \"3.5 years\" or even \"3.1 years\".\n\nBut I do not think people think of years in terms of decimal fraction.\n"},{"id":"105972","messageId":"20090224050400.GC4615@coredump.intra.peff.net","threadId":"17925","inReplyTo":"49A2599E.2030406@trolltech.com","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-24T05:04:00Z","receivedAt":"2009-02-24T05:04:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 23, 2009 at 09:09:02AM +0100, Marius Storm-Olsen wrote:\n\n>> Another option would to give higher resolution in number of years,\n>> like \"3.5 years\" or even \"3.1 years\".\n>\n> And using shorter names for the units would be a no-go?\n>\n> \"3y 2m ago\" <--\n\nPersonally I think that looks terrible. But I recognize that it is\nvery subjective. The only objective thing I can say is that \"m\" is not a\nunique prefix of a time unit, due to \"minutes\". Yes, it is obvious if\nyou see the \"y\" first, but I actually parse the relative time backwards\nin my head and think \"2 minutes ago, oh wait, 3 years, that must be\nmonths\".\n\n-Peff\n"},{"id":"105976","messageId":"20090224054216.GD4615@coredump.intra.peff.net","threadId":"17925","inReplyTo":"7v8wnxun8e.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-24T05:42:16Z","receivedAt":"2009-02-24T05:42:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 23, 2009 at 08:33:37AM -0800, Junio C Hamano wrote:\n\n> Yes, \"75 months\" is unacceptable. I suspect people's mind would not work\n> well with anything larger than 60 months. I've actually thought about\n> \"don't care about months\" point, but 12 months is a long time. You\n> certainly remember there still was a noticeable maturity difference\n> between classmates who were born in the earliest months of the school year\n> and in the last months before graduating grade school. Perhaps after 20\n> years.\n\nI'm not sure human and code development necessarily follow the same\ntimelines. Git wouldn't even be in kindergarten yet. ;)\n\n> > Another option would to give higher resolution in number of years, like\n> > \"3.5 years\" or even \"3.1 years\".\n> \n> But I do not think people think of years in terms of decimal fraction.\n\nI think decimal fraction is overkill. Halves or quarters are more\nreasonable.\n\nBut after sleeping on it, I think \"Y years, M months\" is not that bad.\nSo here is a patch (Eugene, note that this conflicts with your \"fall\nback to DATE_SHORT\" patch).\n\n-- >8 --\nSubject: [PATCH] never fallback relative times to absolute\n\nPreviously, for dates older than 12 months we fell back to\njust giving the absolute time. This can be a bit jarring\nwhen reading a list of times. Instead, let's switch to \"Y\nyears, M months\" for five years, and then just \"Y years\"\nafter that.\n\nNo particular reason on the 5 year cutoff except that it\nseemed reasonable to me.\n\nSigned-off-by: Jeff King \n---\nPlease feel free to mark the 5 years up to 20, or whatever\nyou think is appropriate.\n\nI think this should produce good output in all cases. There\nare a surprising number of corner cases, and I spent an\nembarrassing amount of time looking at the output of \"git\nlog --pretty=tformat:'%ai / %ar'\".\n\nYou could also argue for splitting this into \"support N\nyears, M months\" and then still fall back to absolute time\neventually (whether DATE_SHORT or not).\n\n date.c | 20 +++++++++++++++++++-\n 1 files changed, 19 insertions(+), 1 deletions(-)\n\ndiff --git a/date.c b/date.c\nindex d75dff4..1165d30 100644\n--- a/date.c\n+++ b/date.c\n@@ -133,7 +133,25 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)\n \t\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu months ago\", (diff + 15) / 30);\n \t\t\treturn timebuf;\n \t\t}\n-\t\t/* Else fall back on absolute format.. */\n+\t\t/* Give years and months for 5 years or so */\n+\t\tif (diff < 1825) {\n+\t\t\tunsigned long years = (diff + 183) / 365;\n+\t\t\tunsigned long months = (diff % 365 + 15) / 30;\n+\t\t\tint n;\n+\t\t\tn = snprintf(timebuf, sizeof(timebuf), \"%lu year%s\",\n+\t\t\t\t\tyears, (years > 1 ? \"s\" : \"\"));\n+\t\t\tif (months)\n+\t\t\t\tsnprintf(timebuf + n, sizeof(timebuf) - n,\n+\t\t\t\t\t\", %lu month%s ago\",\n+\t\t\t\t\tmonths, (months > 1 ? \"s\" : \"\"));\n+\t\t\telse\n+\t\t\t\tsnprintf(timebuf + n, sizeof(timebuf) - n,\n+\t\t\t\t\t\" ago\");\n+\t\t\treturn timebuf;\n+\t\t}\n+\t\t/* Otherwise, just years. Centuries is probably overkill. */\n+\t\tsnprintf(timebuf, sizeof(timebuf), \"%lu years ago\", (diff + 183) / 365);\n+\t\treturn timebuf;\n \t}\n \n \tif (mode == DATE_LOCAL)\n-- \n1.6.2.rc1.269.ga7d41\n"},{"id":"105984","messageId":"49A39519.3030308@trolltech.com","threadId":"17925","inReplyTo":"20090224050400.GC4615@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2009-02-24T06:35:05Z","receivedAt":"2009-02-24T06:35:05Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Jeff King said the following on 24.02.2009 06:04:\n> On Mon, Feb 23, 2009 at 09:09:02AM +0100, Marius Storm-Olsen wrote:\n>>> Another option would to give higher resolution in number of\n>>> years, like \"3.5 years\" or even \"3.1 years\".\n>> And using shorter names for the units would be a no-go?\n>> \n>> \"3y 2m ago\" <--\n> \n> Personally I think that looks terrible. But I recognize that it is \n> very subjective. The only objective thing I can say is that \"m\" is\n> not a unique prefix of a time unit, due to \"minutes\". Yes, it is\n> obvious if you see the \"y\" first, but I actually parse the relative\n> time backwards in my head and think \"2 minutes ago, oh wait, 3\n> years, that must be months\".\n\nOk, the standard abbreviation for month is \"mo.\", so\n\n \"3y 2mo. ago\"\n\nthen? ;-)\n\n-- \n.marius [@trolltech.com]\n'if you know what you're doing, it's not research'\n\n"},{"id":"105985","messageId":"20090224063625.GA16389@coredump.intra.peff.net","threadId":"17925","inReplyTo":"49A39519.3030308@trolltech.com","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-24T06:36:25Z","receivedAt":"2009-02-24T06:36:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 24, 2009 at 07:35:05AM +0100, Marius Storm-Olsen wrote:\n\n> Ok, the standard abbreviation for month is \"mo.\", so\n>\n> \"3y 2mo. ago\"\n>\n> then? ;-)\n\nThat is definitely better, but see the patch I just posted elsewhere in\nthe thread.\n\n-Peff\n"},{"id":"105989","messageId":"7v63j0mib5.fsf@gitster.siamese.dyndns.org","threadId":"17925","inReplyTo":"20090224054216.GD4615@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-24T06:59:26Z","receivedAt":"2009-02-24T06:59:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Feb 23, 2009 at 08:33:37AM -0800, Junio C Hamano wrote:\n>\n>> Yes, \"75 months\" is unacceptable. I suspect people's mind would not work\n>> well with anything larger than 60 months. I've actually thought about\n>> \"don't care about months\" point, but 12 months is a long time. You\n>> certainly remember there still was a noticeable maturity difference\n>> between classmates who were born in the earliest months of the school year\n>> and in the last months before graduating grade school. Perhaps after 20\n>> years.\n>\n> I'm not sure human and code development necessarily follow the same\n> timelines. Git wouldn't even be in kindergarten yet. ;)\n>\n>> > Another option would to give higher resolution in number of years, like\n>> > \"3.5 years\" or even \"3.1 years\".\n>> \n>> But I do not think people think of years in terms of decimal fraction.\n>\n> I think decimal fraction is overkill. Halves or quarters are more\n> reasonable.\n>\n> But after sleeping on it, I think \"Y years, M months\" is not that bad.\n\nThat was what I thought. There may be some very convincing reasoning I am\nnot seeing in the proposals to make it ultra-short like \"Y yr M mo\" or\n\"Y.x years\" (i.e. \"we _have_ to keep it under N characters\"threshold), but\nI doubt there is a particular place \"Y years, M months\" would make the\noutput too long to be acceptable.\n"},{"id":"105992","messageId":"20090224070722.GA16566@coredump.intra.peff.net","threadId":"17925","inReplyTo":"7v63j0mib5.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] --date=relative falls back to \"short\" format for commits older than a year","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-24T07:07:22Z","receivedAt":"2009-02-24T07:07:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 23, 2009 at 10:59:26PM -0800, Junio C Hamano wrote:\n\n> That was what I thought. There may be some very convincing reasoning I am\n> not seeing in the proposals to make it ultra-short like \"Y yr M mo\" or\n> \"Y.x years\" (i.e. \"we _have_ to keep it under N characters\"threshold), but\n> I doubt there is a particular place \"Y years, M months\" would make the\n> output too long to be acceptable.\n\nYeah, anything like blame that deals with arbitrary date formats has to\nknow how to handle at least\n\n strlen(\"Sun Feb 22 15:08:25 2009 -0500\") = 30\n\nanyway. Even the default blame format is:\n\n strlen(\"2009-02-24 02:03:25 -0500\") = 25\n\nSo \"Y years, M months ago\" is at least that short for the next ten\nthousand years. I can live with setting the cutoff to just \"years\"\nsomewhere lower than 10,000. :)\n\n-Peff\n"}]}