From: Marius Storm-Olsen <marius@trolltech.com>
Date: Mon, 23 Feb 2009 08:09:02 GMT
Subject: Re: [PATCH 2/2] --date=relative falls back to "short" format for commits older than a year
Message-ID: <49A2599E.2030406@trolltech.com>
In-Reply-To: <20090223031631.GC22348@coredump.intra.peff.net>

Jeff King said the following on 23.02.2009 04:16:
> On Sun, Feb 22, 2009 at 05:44:37PM -0800, Junio C Hamano wrote:
>>> +		/* Otherwise, years. Centuries is probably overkill. */
>>> +		snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
>>> +		return timebuf;
>> I agree this is an improvement.  It irritated me, too.  And I do
>> not think this change falls into the category of bad backward
>> incompatibility.
>> 
>> I was hoping somebody would do a "N years M months", though.
> 
> I thought about that, but I wanted to keep the maximum size down
> for column output (like in git-blame). Which is why I bumped the
> "use months" limit to 24 months instead of 12.
> 
> And that limit can also be tweaked.  Surely at some point there is
> a range where you no longer care about the months and "N years" has
> high enough resolution. But there is also a point where "N months"
> gets cumbersome (75 months is a more annoying than "around 6
> years"). The question is whether we reach the "cumbersome" point
> before we reach the "don't care about months" point.
> 
> Another option would to give higher resolution in number of years,
> like "3.5 years" or even "3.1 years".

And using shorter names for the units would be a no-go?

   "3y 2m ago"    <--
   "3 years ago"
   "3 months ago"
   "3 weeks ago"
   "3 days ago"
   "3 hours ago"
   "3 mins ago"   <--
   "3 secs ago"   <--

-- 
.marius [@trolltech.com]
'if you know what you're doing, it's not research'