Re: [PATCH 2/2] --date=relative falls back to "short" format for commits older than a year
- From
Jeff King <peff@peff.net>
- Date
- Feb 24, 2009, 05:42 UTC
- Message-ID
- <20090224054216.GD4615@coredump.intra.peff.net>
- In-Reply-To
- <7v8wnxun8e.fsf@gitster.siamese.dyndns.org>
On Mon, Feb 23, 2009 at 08:33:37AM -0800, Junio C Hamano wrote:
Show 7 quoted lines
> Yes, "75 months" is unacceptable. I suspect people's mind would not work > well with anything larger than 60 months. I've actually thought about > "don't care about months" point, but 12 months is a long time. You > certainly remember there still was a noticeable maturity difference > between classmates who were born in the earliest months of the school year > and in the last months before graduating grade school. Perhaps after 20 > years.
I'm not sure human and code development necessarily follow the same timelines. Git wouldn't even be in kindergarten yet. ;)
> > Another option would to give higher resolution in number of years, like > > "3.5 years" or even "3.1 years". > > But I do not think people think of years in terms of decimal fraction.
I think decimal fraction is overkill. Halves or quarters are more reasonable.
But after sleeping on it, I think "Y years, M months" is not that bad. So here is a patch (Eugene, note that this conflicts with your "fall back to DATE_SHORT" patch).
-- >8 -- Subject: [PATCH] never fallback relative times to absolute
Previously, for dates older than 12 months we fell back to just giving the absolute time. This can be a bit jarring when reading a list of times. Instead, let's switch to "Y years, M months" for five years, and then just "Y years" after that.
No particular reason on the 5 year cutoff except that it seemed reasonable to me.
Signed-off-by: Jeff King <peff@peff.net> --- Please feel free to mark the 5 years up to 20, or whatever you think is appropriate.
I think this should produce good output in all cases. There are a surprising number of corner cases, and I spent an embarrassing amount of time looking at the output of "git log --pretty=tformat:'%ai / %ar'".
You could also argue for splitting this into "support N years, M months" and then still fall back to absolute time eventually (whether DATE_SHORT or not).
date.c | 20 +++++++++++++++++++- 1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/date.c b/date.c index d75dff4..1165d30 100644 --- a/date.c +++ b/date.c @@ -133,7 +133,25 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode) snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30); return timebuf; } - /* Else fall back on absolute format.. */ + /* Give years and months for 5 years or so */ + if (diff < 1825) { + unsigned long years = (diff + 183) / 365; + unsigned long months = (diff % 365 + 15) / 30; + int n; + n = snprintf(timebuf, sizeof(timebuf), "%lu year%s", + years, (years > 1 ? "s" : "")); + if (months) + snprintf(timebuf + n, sizeof(timebuf) - n, + ", %lu month%s ago", + months, (months > 1 ? "s" : "")); + else + snprintf(timebuf + n, sizeof(timebuf) - n, + " ago"); + return timebuf; + } + /* Otherwise, just years. Centuries is probably overkill. */ + snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365); + return timebuf; } if (mode == DATE_LOCAL)
-- 1.6.2.rc1.269.ga7d41