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

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

[Petr Baudis]

  Hi,

On Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:
> I see gitweb is much more usable (faster) than a few months ago, but
> there is one thing a bit problematic: in the history of patches I'm
> very often interested in which kernel version of Linus' tree the patch
> appeared for the first time. If it's not some big problem, and maybe
> somebody else finds this useful too, I'd really appreciate adding such
> a feature.

  in git terms, you'd like gitweb to provide output for command:

	git describe --contains

This is interesting feature request. I guess the support would be nice,
though in theory this operation can be a bit resource-intensive in case
there is not many tags and a lot of development (with uncached
repository, this query took quite a bit of time on my copy of the kernel
git tree). Probably this should be an optional feature and somehow dwell
on a separate page, which doesn't fit too well in the current gitweb
page structure...

> Petr, I hope there is no necessity to subscribe to the git list for
> this one question, so I'd really feel greteful for forwarding, if you
> find this request reasonable.

  Yes, there is no necessity - you can post this on the git mailing list
without subscribing yourself.

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

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

[Jarek Poplawski]

Petr Baudis wrote, On 11/20/2007 10:59 PM:

>   Hi,
> 
> On Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:
>> I see gitweb is much more usable (faster) than a few months ago, but
>> there is one thing a bit problematic: in the history of patches I'm
>> very often interested in which kernel version of Linus' tree the patch
>> appeared for the first time. If it's not some big problem, and maybe
>> somebody else finds this useful too, I'd really appreciate adding such
>> a feature.
> 
>   in git terms, you'd like gitweb to provide output for command:
> 
> 	git describe --contains
> 
> This is interesting feature request. I guess the support would be nice,
> though in theory this operation can be a bit resource-intensive in case
> there is not many tags and a lot of development (with uncached
> repository, this query took quite a bit of time on my copy of the kernel
> git tree). Probably this should be an optional feature and somehow dwell
> on a separate page, which doesn't fit too well in the current gitweb
> page structure...
 

I don't know git, but it seems, at least if done for web only, this
shouldn't be so 'heavy'. It could be a 'simple' translation of commit
date by querying a small database with kernel versions & dates. And it
would suffice if it were shown on the commit page only. But, of course,
it's not urgent at all! (And alas I'm no webmaster, so I can miss
something.)

>> Petr, I hope there is no necessity to subscribe to the git list for
>> this one question, so I'd really feel greteful for forwarding, if you
>> find this request reasonable.
> 
>   Yes, there is no necessity - you can post this on the git mailing list
> without subscribing yourself.


Great! I misunderstood the page message. Btw., I know it's not the kernel,
but IMHO there should be some place for it in the MAINTAINERS!

Thanks,
Jarek P.

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

[J. Bruce Fields]

On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:
> I don't know git, but it seems, at least if done for web only, this
> shouldn't be so 'heavy'. It could be a 'simple' translation of commit
> date by querying a small database with kernel versions & dates.

If I create a commit in my linux working repo today, but Linus doesn't
merge it into his repository until after he releases 2.6.24, then my
commit will be created with an earlier date than 2.6.24, even though it
isn't included until 2.6.25.

So you have to actually examine the history graph to figure this out
this sort of thing.

--b.

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

[Jarek Poplawski]

On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:
> On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:
> > I don't know git, but it seems, at least if done for web only, this
> > shouldn't be so 'heavy'. It could be a 'simple' translation of commit
> > date by querying a small database with kernel versions & dates.
> 
> If I create a commit in my linux working repo today, but Linus doesn't
> merge it into his repository until after he releases 2.6.24, then my
> commit will be created with an earlier date than 2.6.24, even though it
> isn't included until 2.6.25.
> 
> So you have to actually examine the history graph to figure this out
> this sort of thing.

Of course, you are right, and I probably miss something, but to be
sure we think about the same thing let's look at some example: so, I
open a page with current Linus' tree, go to something titled:
/pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history

and see:
2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...
and just below something with 2007-08-14 date.

Accidentally, I can remember this patch introduced many changes, and
this big interval in dates suggests some waiting. Then I look at the
commit, and there are 2 dates visible, so the patch really was created
earlier. Then I go back to:
/pub/scm / linux/kernel/git/torvalds/linux-2.6.git / summary

and at the bottom I can see this:

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

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.

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.

Regards,
Jarek P.

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

[Jarek Poplawski]

On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:
...
> Of course, you are right, and I probably miss something, but to be
> sure we think about the same thing let's look at some example: so, I
> open a page with current Linus' tree, go to something titled:
> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history

I've forgotten to mention it's: 

[linux/kernel/git/torvalds/linux-2.6.git] / net / core / dev.c

> and see:
> 2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...
> and just below something with 2007-08-14 date.

Jarek P.

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

[Petr Baudis]

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

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

[Kay Sievers]

On Nov 21, 2007 8:52 AM, Jarek Poplawski <jarkao2@o2.pl> wrote:
> On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:
> > On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:
> > > I don't know git, but it seems, at least if done for web only, this
> > > shouldn't be so 'heavy'. It could be a 'simple' translation of commit
> > > date by querying a small database with kernel versions & dates.
> >
> > If I create a commit in my linux working repo today, but Linus doesn't
> > merge it into his repository until after he releases 2.6.24, then my
> > commit will be created with an earlier date than 2.6.24, even though it
> > isn't included until 2.6.25.
> >
> > So you have to actually examine the history graph to figure this out
> > this sort of thing.
>
> Of course, you are right, and I probably miss something, but to be
> sure we think about the same thing let's look at some example: so, I
> open a page with current Linus' tree, go to something titled:
> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history
>
> and see:
> 2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...
> and just below something with 2007-08-14 date.
>
> Accidentally, I can remember this patch introduced many changes, and
> this big interval in dates suggests some waiting. Then I look at the
> commit, and there are 2 dates visible, so the patch really was created
> earlier. Then I go back to:
> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / summary
>
> and at the bottom I can see this:
>
> ...
> 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!
>
> 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.
>
> 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.

The "plain" view of the patch has the "version" included:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=bea3348eef27e6044b6161fd04c3152215f96411

  From: Stephen Hemminger <shemminger@linux-foundation.org>
  Date: Wed, 3 Oct 2007 23:41:36 +0000 (-0700)
  Subject: [NET]: Make NAPI polling independent of struct net_device objects.
  X-Git-Tag: v2.6.24-rc1~1454^2~841

Is that what you are looking for?

Kay

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

[Jakub Narebski]

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

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

[Jarek Poplawski]

Kay Sievers wrote, On 11/21/2007 05:06 PM:

> On Nov 21, 2007 8:52 AM, Jarek Poplawski <jarkao2@o2.pl> wrote:
>> On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:
>>> On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:
>>>> I don't know git, but it seems, at least if done for web only, this
>>>> shouldn't be so 'heavy'. It could be a 'simple' translation of commit
>>>> date by querying a small database with kernel versions & dates.
>>> If I create a commit in my linux working repo today, but Linus doesn't
>>> merge it into his repository until after he releases 2.6.24, then my
>>> commit will be created with an earlier date than 2.6.24, even though it
>>> isn't included until 2.6.25.
>>>
>>> So you have to actually examine the history graph to figure this out
>>> this sort of thing.
>> Of course, you are right, and I probably miss something, but to be
>> sure we think about the same thing let's look at some example: so, I
>> open a page with current Linus' tree, go to something titled:
>> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history
>>
>> and see:
>> 2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...
>> and just below something with 2007-08-14 date.
>>
>> Accidentally, I can remember this patch introduced many changes, and
>> this big interval in dates suggests some waiting. Then I look at the
>> commit, and there are 2 dates visible, so the patch really was created
>> earlier. Then I go back to:
>> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / summary
>>
>> and at the bottom I can see this:
>>
>> ...
>> 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!
>>
>> 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.
>>
>> 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.
> 
> The "plain" view of the patch has the "version" included:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=bea3348eef27e6044b6161fd04c3152215f96411
> 
>   From: Stephen Hemminger <shemminger@linux-foundation.org>
>   Date: Wed, 3 Oct 2007 23:41:36 +0000 (-0700)
>   Subject: [NET]: Make NAPI polling independent of struct net_device objects.
>   X-Git-Tag: v2.6.24-rc1~1454^2~841
> 
> Is that what you are looking for?
> 

YeeeS!!! You are a genius with eagle's eyes!

I've suspected from the beginning something like this has to be
there... And I really tried to find this before sending this. But,
as a matter of fact I didn't even try this "plain" or rather "raw",
because I've somehow thought "raw" is just plain text, so the same
only without html tags!? So, now I know, and it's enough to me. But,
... maybe it should be on this "complex" page as well?

Thanks very much,
Jarek P.

PS: I hope eagles can see in English at least the same as in Polish,
and more than I can see in my dictionary now!

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

[Jarek Poplawski]

Petr Baudis wrote, On 11/21/2007 04:18 PM:

> 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, it's so easy! Great! It seems I've to get used to this clicking
more. It seems I've become too cautious with this, when I've really
- really, waited after each click there. (I mean a few months ago,
and my connection was the same; sometimes, one such click took one
whole break for coffee.)

I seems, there are simply two kinds of people wrt. calendar/time. I'm
usually happy if I can figure by myself which day of week is today, but
I wouldn't even try with something like 4 days ago. But I understand
I'm not the brightest here...

So, maybe, some day, with: linux-kernel-for-dummies.org such things
could be reconsidered...

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


It looks, after Kay's notice, my main problem is solved. And your current
explanations are also very precious to me. Probably some things considered
here could be done a bit better in the future, but I guess there is enough
urgent work with git or kernel too, so let's say it's OK for now!

Thanks every good git people!
Jarek P.