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

[Petr Baudis <pasky@suse.cz>]

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...

At any rate, if you click at the tag name, you should get tag page with
full date.

> So, I go to the: http://www.eu.kernel.org/pub/linux/kernel/v2.6/, 
> do some scrolling, look at this:
> ChangeLog-2.6.23             09-Oct-2007 20:38  3.8M  
> 
> and only now I can guess, this napi patch didn't manage to 2.6.23.
> Of course, usually I've to do a few more clicks and reading to make
> sure where it really started.
> 
> So, this could suggest this 2007-10-10 (probably stored with time
> too), could be useful here... but it seems, I'm wrong.

Yes, there are three scenarios:

(i) The patch has been _created_ after the release date. It can't be in
the release.
(ii) The patch has been created before the release date, but _committed_
after the release date. It can't be in the release either.
(iii) The patch has been committed before the release date. It _still_
might not be in the release if it comes from a different branch.
Imagine, say, tglx accepting the patch in his branch, then Linus
releasing new kernel version, and only _then_ Linus merging tglx's
branch.

So the time information isn't really too useful if you want to be any
sort of reliable.

> 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. ;-)

-- 
				Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish.		-- Marshall McLuhan