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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:  <fi1n94$l8r$1@ger.gmane.org>
Date:	Wed, 21 Nov 2007 17:44:21 +0100
From:	Jakub Narebski <jnareb@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	git@...r.kernel.org
Subject:  Re: gitweb: kernel versions in the history (feature request, probably)

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/