Petr Baudis wrote:
> 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.
[...]
>> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
