Re: gitweb: kernel versions in the history (feature request, probably)

From: Jakub Narebski <jnareb@gmail.com>
Date: Nov 21, 2007, 16:44 UTC
Message-ID: <fi1n94$l8r$1@ger.gmane.org>
In-Reply-To: <20071121151831.GO1001@machine.or.cz>

Petr Baudis wrote:

Show 14 quoted lines

> On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:
>> ...
>> tags
>> 4 days ago   v2.6.24-rc3     Linux 2.6.24-rc3
>> 2 weeks ago  v2.6.24-rc2     Linux 2.6.24-rc2
>> 4 weeks ago  v2.6.24-rc1     Linux 2.6.24-rc1
>> 6 weeks ago  v2.6.23         Linux 2.6.23
>> 
>> which drives me crazy, because, without looking at the calendar, and
>> calculator, I don't really know which month was 6 weeks ago, and 4
>> days ago, either!
> 
> I have myself never been sure if the relative times are a good idea or
> not. :-) Sometimes I hate them, sometimes they are more convenient...

Additionally if we want support caching in gitweb, and not need to rewrite cached file, then we should use absolute time everywhere in gitweb (perhaps rewriting to relative using JavaScript, or output filter,...).

There is some cutoff where gitweb stops displaying relative time and displays date; gitweb should also always provide absolute date in tooltip on mouseover (in title attribute), if it does not then it is a bug.

[...]

Show 11 quoted lines

>> Of course, this problem doesn't look so hard if we forget about
>> git internals: I can imagine keeping a simple database, which
>> could simply retrieve commit numbers from these ChangeLogs, and
>> connecting this with gitweb's commit page as well... For
>> performance reasons, doing it only for stable and testing, so with
>> -rc 'precision' would be very helpful too.
> 
> It isn't too hard if we don't forget about git internals either. It's
> just that getting this information might not be cheap. But maybe I'm
> wrong and this won't be a problem for sane projects. Someone should post
> a patch. ;-)

Perhaps the following solution would be good idea:
 1. use git-describe to find nearest commit
 2. if it took long / if the distance from tag is large
    then make some special tag denoting calculated git-describe e.g.
    in tag name
 3. if found tag is helper tag created in previous step, recaulculate
    true git-describe from it, or just output closest contained tag.
This needs write access to repository, although can be done using simple
database... what do you think?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git