{"thread":{"id":"10946","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","startedAt":"2007-11-20T21:59:04Z","lastAt":"2007-11-21T20:16:26Z","messageCount":10,"participants":["Petr Baudis","Jarek Poplawski","J. Bruce Fields","Kay Sievers","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"60440","messageId":"20071120215904.GF1001@machine.or.cz","threadId":"10946","inReplyTo":"20071120142042.GA4157@ff.dom.local","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-11-20T21:59:04Z","receivedAt":"2007-11-20T21:59:04Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:\n> I see gitweb is much more usable (faster) than a few months ago, but\n> there is one thing a bit problematic: in the history of patches I'm\n> very often interested in which kernel version of Linus' tree the patch\n> appeared for the first time. If it's not some big problem, and maybe\n> somebody else finds this useful too, I'd really appreciate adding such\n> a feature.\n\n in git terms, you'd like gitweb to provide output for command:\n\n\tgit describe --contains\n\nThis is interesting feature request. I guess the support would be nice,\nthough in theory this operation can be a bit resource-intensive in case\nthere is not many tags and a lot of development (with uncached\nrepository, this query took quite a bit of time on my copy of the kernel\ngit tree). Probably this should be an optional feature and somehow dwell\non a separate page, which doesn't fit too well in the current gitweb\npage structure...\n\n> Petr, I hope there is no necessity to subscribe to the git list for\n> this one question, so I'd really feel greteful for forwarding, if you\n> find this request reasonable.\n\n Yes, there is no necessity - you can post this on the git mailing list\nwithout subscribing yourself.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nWe don't know who it was that discovered water, but we're pretty sure\nthat it wasn't a fish.\t\t-- Marshall McLuhan\n"},{"id":"60443","messageId":"47436E0F.6080003@o2.pl","threadId":"10946","inReplyTo":"20071120215904.GF1001@machine.or.cz","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"Jarek Poplawski","fromEmail":"jarkao2@o2.pl","sentAt":"2007-11-20T23:30:23Z","receivedAt":"2007-11-20T23:30:23Z","isPatch":false,"sender":{"key":"jarkao2@o2.pl","avatar":null},"body":"Petr Baudis wrote, On 11/20/2007 10:59 PM:\n\n> Hi,\n> \n> On Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:\n>> I see gitweb is much more usable (faster) than a few months ago, but\n>> there is one thing a bit problematic: in the history of patches I'm\n>> very often interested in which kernel version of Linus' tree the patch\n>> appeared for the first time. If it's not some big problem, and maybe\n>> somebody else finds this useful too, I'd really appreciate adding such\n>> a feature.\n> \n> in git terms, you'd like gitweb to provide output for command:\n> \n> \tgit describe --contains\n> \n> This is interesting feature request. I guess the support would be nice,\n> though in theory this operation can be a bit resource-intensive in case\n> there is not many tags and a lot of development (with uncached\n> repository, this query took quite a bit of time on my copy of the kernel\n> git tree). Probably this should be an optional feature and somehow dwell\n> on a separate page, which doesn't fit too well in the current gitweb\n> page structure...\n \n\nI don't know git, but it seems, at least if done for web only, this\nshouldn't be so 'heavy'. It could be a 'simple' translation of commit\ndate by querying a small database with kernel versions & dates. And it\nwould suffice if it were shown on the commit page only. But, of course,\nit's not urgent at all! (And alas I'm no webmaster, so I can miss\nsomething.)\n\n>> Petr, I hope there is no necessity to subscribe to the git list for\n>> this one question, so I'd really feel greteful for forwarding, if you\n>> find this request reasonable.\n> \n> Yes, there is no necessity - you can post this on the git mailing list\n> without subscribing yourself.\n\n\nGreat! I misunderstood the page message. Btw., I know it's not the kernel,\nbut IMHO there should be some place for it in the MAINTAINERS!\n\nThanks,\nJarek P.\n"},{"id":"60450","messageId":"20071121032009.GB4175@fieldses.org","threadId":"10946","inReplyTo":"47436E0F.6080003@o2.pl","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-21T03:20:09Z","receivedAt":"2007-11-21T03:20:09Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:\n> I don't know git, but it seems, at least if done for web only, this\n> shouldn't be so 'heavy'. It could be a 'simple' translation of commit\n> date by querying a small database with kernel versions & dates.\n\nIf I create a commit in my linux working repo today, but Linus doesn't\nmerge it into his repository until after he releases 2.6.24, then my\ncommit will be created with an earlier date than 2.6.24, even though it\nisn't included until 2.6.25.\n\nSo you have to actually examine the history graph to figure this out\nthis sort of thing.\n\n--b.\n"},{"id":"60479","messageId":"20071121075217.GA1642@ff.dom.local","threadId":"10946","inReplyTo":"20071121032009.GB4175@fieldses.org","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"Jarek Poplawski","fromEmail":"jarkao2@o2.pl","sentAt":"2007-11-21T07:52:17Z","receivedAt":"2007-11-21T07:52:17Z","isPatch":false,"sender":{"key":"jarkao2@o2.pl","avatar":null},"body":"On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:\n> On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:\n> > I don't know git, but it seems, at least if done for web only, this\n> > shouldn't be so 'heavy'. It could be a 'simple' translation of commit\n> > date by querying a small database with kernel versions & dates.\n> \n> If I create a commit in my linux working repo today, but Linus doesn't\n> merge it into his repository until after he releases 2.6.24, then my\n> commit will be created with an earlier date than 2.6.24, even though it\n> isn't included until 2.6.25.\n> \n> So you have to actually examine the history graph to figure this out\n> this sort of thing.\n\nOf course, you are right, and I probably miss something, but to be\nsure we think about the same thing let's look at some example: so, I\nopen a page with current Linus' tree, go to something titled:\n/pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history\n\nand see:\n2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...\nand just below something with 2007-08-14 date.\n\nAccidentally, I can remember this patch introduced many changes, and\nthis big interval in dates suggests some waiting. Then I look at the\ncommit, and there are 2 dates visible, so the patch really was created\nearlier. Then I go back to:\n/pub/scm / linux/kernel/git/torvalds/linux-2.6.git / summary\n\nand at the bottom I can see this:\n\n...\ntags\n4 days ago \tv2.6.24-rc3 \tLinux 2.6.24-rc3\n2 weeks ago \tv2.6.24-rc2 \tLinux 2.6.24-rc2\n4 weeks ago \tv2.6.24-rc1 \tLinux 2.6.24-rc1\n6 weeks ago \tv2.6.23 \tLinux 2.6.23\n\nwhich drives me crazy, because, without looking at the calendar, and\ncalculator, I don't really know which month was 6 weeks ago, and 4\ndays ago, either!\n\nSo, I go to the: http://www.eu.kernel.org/pub/linux/kernel/v2.6/, \ndo some scrolling, look at this:\nChangeLog-2.6.23 09-Oct-2007 20:38 3.8M \n\nand only now I can guess, this napi patch didn't manage to 2.6.23.\nOf course, usually I've to do a few more clicks and reading to make\nsure where it really started.\n\nSo, this could suggest this 2007-10-10 (probably stored with time\ntoo), could be useful here... but it seems, I'm wrong.\n\nOf course, this problem doesn't look so hard if we forget about\ngit internals: I can imagine keeping a simple database, which\ncould simply retrieve commit numbers from these ChangeLogs, and\nconnecting this with gitweb's commit page as well... For\nperformance reasons, doing it only for stable and testing, so with\n-rc 'precision' would be very helpful too.\n\nRegards,\nJarek P.\n"},{"id":"60482","messageId":"20071121080925.GA2183@ff.dom.local","threadId":"10946","inReplyTo":"20071121075217.GA1642@ff.dom.local","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"Jarek Poplawski","fromEmail":"jarkao2@o2.pl","sentAt":"2007-11-21T08:09:25Z","receivedAt":"2007-11-21T08:09:25Z","isPatch":false,"sender":{"key":"jarkao2@o2.pl","avatar":null},"body":"On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:\n...\n> Of course, you are right, and I probably miss something, but to be\n> sure we think about the same thing let's look at some example: so, I\n> open a page with current Linus' tree, go to something titled:\n> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history\n\nI've forgotten to mention it's: \n\n[linux/kernel/git/torvalds/linux-2.6.git] / net / core / dev.c\n\n> and see:\n> 2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...\n> and just below something with 2007-08-14 date.\n\nJarek P.\n"},{"id":"60525","messageId":"20071121151831.GO1001@machine.or.cz","threadId":"10946","inReplyTo":"20071121075217.GA1642@ff.dom.local","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-11-21T15:18:31Z","receivedAt":"2007-11-21T15:18:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:\n> ...\n> tags\n> 4 days ago \tv2.6.24-rc3 \tLinux 2.6.24-rc3\n> 2 weeks ago \tv2.6.24-rc2 \tLinux 2.6.24-rc2\n> 4 weeks ago \tv2.6.24-rc1 \tLinux 2.6.24-rc1\n> 6 weeks ago \tv2.6.23 \tLinux 2.6.23\n> \n> which drives me crazy, because, without looking at the calendar, and\n> calculator, I don't really know which month was 6 weeks ago, and 4\n> days ago, either!\n\nI have myself never been sure if the relative times are a good idea or\nnot. :-) Sometimes I hate them, sometimes they are more convenient...\n\nAt any rate, if you click at the tag name, you should get tag page with\nfull date.\n\n> So, I go to the: http://www.eu.kernel.org/pub/linux/kernel/v2.6/, \n> do some scrolling, look at this:\n> ChangeLog-2.6.23 09-Oct-2007 20:38 3.8M \n> \n> and only now I can guess, this napi patch didn't manage to 2.6.23.\n> Of course, usually I've to do a few more clicks and reading to make\n> sure where it really started.\n> \n> So, this could suggest this 2007-10-10 (probably stored with time\n> too), could be useful here... but it seems, I'm wrong.\n\nYes, there are three scenarios:\n\n(i) The patch has been _created_ after the release date. It can't be in\nthe release.\n(ii) The patch has been created before the release date, but _committed_\nafter the release date. It can't be in the release either.\n(iii) The patch has been committed before the release date. It _still_\nmight not be in the release if it comes from a different branch.\nImagine, say, tglx accepting the patch in his branch, then Linus\nreleasing new kernel version, and only _then_ Linus merging tglx's\nbranch.\n\nSo the time information isn't really too useful if you want to be any\nsort of reliable.\n\n> Of course, this problem doesn't look so hard if we forget about\n> git internals: I can imagine keeping a simple database, which\n> could simply retrieve commit numbers from these ChangeLogs, and\n> connecting this with gitweb's commit page as well... For\n> performance reasons, doing it only for stable and testing, so with\n> -rc 'precision' would be very helpful too.\n\nIt isn't too hard if we don't forget about git internals either. It's\njust that getting this information might not be cheap. But maybe I'm\nwrong and this won't be a problem for sane projects. Someone should post\na patch. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nWe don't know who it was that discovered water, but we're pretty sure\nthat it wasn't a fish.\t\t-- Marshall McLuhan\n"},{"id":"60535","messageId":"3ae72650711210806v1e7daa2fq729a7593def99ef7@mail.gmail.com","threadId":"10946","inReplyTo":"20071121075217.GA1642@ff.dom.local","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2007-11-21T16:06:39Z","receivedAt":"2007-11-21T16:06:39Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Nov 21, 2007 8:52 AM, Jarek Poplawski wrote:\n> On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:\n> > On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:\n> > > I don't know git, but it seems, at least if done for web only, this\n> > > shouldn't be so 'heavy'. It could be a 'simple' translation of commit\n> > > date by querying a small database with kernel versions & dates.\n> >\n> > If I create a commit in my linux working repo today, but Linus doesn't\n> > merge it into his repository until after he releases 2.6.24, then my\n> > commit will be created with an earlier date than 2.6.24, even though it\n> > isn't included until 2.6.25.\n> >\n> > So you have to actually examine the history graph to figure this out\n> > this sort of thing.\n>\n> Of course, you are right, and I probably miss something, but to be\n> sure we think about the same thing let's look at some example: so, I\n> open a page with current Linus' tree, go to something titled:\n> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history\n>\n> and see:\n> 2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...\n> and just below something with 2007-08-14 date.\n>\n> Accidentally, I can remember this patch introduced many changes, and\n> this big interval in dates suggests some waiting. Then I look at the\n> commit, and there are 2 dates visible, so the patch really was created\n> earlier. Then I go back to:\n> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / summary\n>\n> and at the bottom I can see this:\n>\n> ...\n> tags\n> 4 days ago v2.6.24-rc3 Linux 2.6.24-rc3\n> 2 weeks ago v2.6.24-rc2 Linux 2.6.24-rc2\n> 4 weeks ago v2.6.24-rc1 Linux 2.6.24-rc1\n> 6 weeks ago v2.6.23 Linux 2.6.23\n>\n> which drives me crazy, because, without looking at the calendar, and\n> calculator, I don't really know which month was 6 weeks ago, and 4\n> days ago, either!\n>\n> So, I go to the: http://www.eu.kernel.org/pub/linux/kernel/v2.6/,\n> do some scrolling, look at this:\n> ChangeLog-2.6.23 09-Oct-2007 20:38 3.8M\n>\n> and only now I can guess, this napi patch didn't manage to 2.6.23.\n> Of course, usually I've to do a few more clicks and reading to make\n> sure where it really started.\n>\n> So, this could suggest this 2007-10-10 (probably stored with time\n> too), could be useful here... but it seems, I'm wrong.\n>\n> Of course, this problem doesn't look so hard if we forget about\n> git internals: I can imagine keeping a simple database, which\n> could simply retrieve commit numbers from these ChangeLogs, and\n> connecting this with gitweb's commit page as well... For\n> performance reasons, doing it only for stable and testing, so with\n> -rc 'precision' would be very helpful too.\n\nThe \"plain\" view of the patch has the \"version\" included:\nhttp://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=bea3348eef27e6044b6161fd04c3152215f96411\n\n From: Stephen Hemminger \n Date: Wed, 3 Oct 2007 23:41:36 +0000 (-0700)\n Subject: [NET]: Make NAPI polling independent of struct net_device objects.\n X-Git-Tag: v2.6.24-rc1~1454^2~841\n\nIs that what you are looking for?\n\nKay\n"},{"id":"60544","messageId":"fi1n94$l8r$1@ger.gmane.org","threadId":"10946","inReplyTo":"20071121151831.GO1001@machine.or.cz","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-21T16:44:21Z","receivedAt":"2007-11-21T16:44:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n\n> On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:\n>> ...\n>> tags\n>> 4 days ago v2.6.24-rc3 Linux 2.6.24-rc3\n>> 2 weeks ago v2.6.24-rc2 Linux 2.6.24-rc2\n>> 4 weeks ago v2.6.24-rc1 Linux 2.6.24-rc1\n>> 6 weeks ago v2.6.23 Linux 2.6.23\n>> \n>> which drives me crazy, because, without looking at the calendar, and\n>> calculator, I don't really know which month was 6 weeks ago, and 4\n>> days ago, either!\n> \n> I have myself never been sure if the relative times are a good idea or\n> not. :-) Sometimes I hate them, sometimes they are more convenient...\n\nAdditionally if we want support caching in gitweb, and not need to rewrite\ncached file, then we should use absolute time everywhere in gitweb (perhaps\nrewriting to relative using JavaScript, or output filter,...).\n\nThere is some cutoff where gitweb stops displaying relative time and\ndisplays date; gitweb should also always provide absolute date in tooltip\non mouseover (in title attribute), if it does not then it is a bug.\n\n[...]\n>> Of course, this problem doesn't look so hard if we forget about\n>> git internals: I can imagine keeping a simple database, which\n>> could simply retrieve commit numbers from these ChangeLogs, and\n>> connecting this with gitweb's commit page as well... For\n>> performance reasons, doing it only for stable and testing, so with\n>> -rc 'precision' would be very helpful too.\n> \n> It isn't too hard if we don't forget about git internals either. It's\n> just that getting this information might not be cheap. But maybe I'm\n> wrong and this won't be a problem for sane projects. Someone should post\n> a patch. ;-)\n\nPerhaps the following solution would be good idea:\n 1. use git-describe to find nearest commit\n 2. if it took long / if the distance from tag is large\n then make some special tag denoting calculated git-describe e.g.\n in tag name\n 3. if found tag is helper tag created in previous step, recaulculate\n true git-describe from it, or just output closest contained tag.\nThis needs write access to repository, although can be done using simple\ndatabase... what do you think?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"60555","messageId":"47448726.6060709@o2.pl","threadId":"10946","inReplyTo":"3ae72650711210806v1e7daa2fq729a7593def99ef7@mail.gmail.com","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"Jarek Poplawski","fromEmail":"jarkao2@o2.pl","sentAt":"2007-11-21T19:29:42Z","receivedAt":"2007-11-21T19:29:42Z","isPatch":false,"sender":{"key":"jarkao2@o2.pl","avatar":null},"body":"Kay Sievers wrote, On 11/21/2007 05:06 PM:\n\n> On Nov 21, 2007 8:52 AM, Jarek Poplawski wrote:\n>> On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:\n>>> On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:\n>>>> I don't know git, but it seems, at least if done for web only, this\n>>>> shouldn't be so 'heavy'. It could be a 'simple' translation of commit\n>>>> date by querying a small database with kernel versions & dates.\n>>> If I create a commit in my linux working repo today, but Linus doesn't\n>>> merge it into his repository until after he releases 2.6.24, then my\n>>> commit will be created with an earlier date than 2.6.24, even though it\n>>> isn't included until 2.6.25.\n>>>\n>>> So you have to actually examine the history graph to figure this out\n>>> this sort of thing.\n>> Of course, you are right, and I probably miss something, but to be\n>> sure we think about the same thing let's look at some example: so, I\n>> open a page with current Linus' tree, go to something titled:\n>> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history\n>>\n>> and see:\n>> 2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...\n>> and just below something with 2007-08-14 date.\n>>\n>> Accidentally, I can remember this patch introduced many changes, and\n>> this big interval in dates suggests some waiting. Then I look at the\n>> commit, and there are 2 dates visible, so the patch really was created\n>> earlier. Then I go back to:\n>> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / summary\n>>\n>> and at the bottom I can see this:\n>>\n>> ...\n>> tags\n>> 4 days ago v2.6.24-rc3 Linux 2.6.24-rc3\n>> 2 weeks ago v2.6.24-rc2 Linux 2.6.24-rc2\n>> 4 weeks ago v2.6.24-rc1 Linux 2.6.24-rc1\n>> 6 weeks ago v2.6.23 Linux 2.6.23\n>>\n>> which drives me crazy, because, without looking at the calendar, and\n>> calculator, I don't really know which month was 6 weeks ago, and 4\n>> days ago, either!\n>>\n>> So, I go to the: http://www.eu.kernel.org/pub/linux/kernel/v2.6/,\n>> do some scrolling, look at this:\n>> ChangeLog-2.6.23 09-Oct-2007 20:38 3.8M\n>>\n>> and only now I can guess, this napi patch didn't manage to 2.6.23.\n>> Of course, usually I've to do a few more clicks and reading to make\n>> sure where it really started.\n>>\n>> So, this could suggest this 2007-10-10 (probably stored with time\n>> too), could be useful here... but it seems, I'm wrong.\n>>\n>> Of course, this problem doesn't look so hard if we forget about\n>> git internals: I can imagine keeping a simple database, which\n>> could simply retrieve commit numbers from these ChangeLogs, and\n>> connecting this with gitweb's commit page as well... For\n>> performance reasons, doing it only for stable and testing, so with\n>> -rc 'precision' would be very helpful too.\n> \n> The \"plain\" view of the patch has the \"version\" included:\n> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=bea3348eef27e6044b6161fd04c3152215f96411\n> \n> From: Stephen Hemminger \n> Date: Wed, 3 Oct 2007 23:41:36 +0000 (-0700)\n> Subject: [NET]: Make NAPI polling independent of struct net_device objects.\n> X-Git-Tag: v2.6.24-rc1~1454^2~841\n> \n> Is that what you are looking for?\n> \n\nYeeeS!!! You are a genius with eagle's eyes!\n\nI've suspected from the beginning something like this has to be\nthere... And I really tried to find this before sending this. But,\nas a matter of fact I didn't even try this \"plain\" or rather \"raw\",\nbecause I've somehow thought \"raw\" is just plain text, so the same\nonly without html tags!? So, now I know, and it's enough to me. But,\n... maybe it should be on this \"complex\" page as well?\n\nThanks very much,\nJarek P.\n\nPS: I hope eagles can see in English at least the same as in Polish,\nand more than I can see in my dictionary now!\n"},{"id":"60562","messageId":"4744921A.6000801@o2.pl","threadId":"10946","inReplyTo":"20071121151831.GO1001@machine.or.cz","subject":"Re: gitweb: kernel versions in the history (feature request, probably)","fromName":"Jarek Poplawski","fromEmail":"jarkao2@o2.pl","sentAt":"2007-11-21T20:16:26Z","receivedAt":"2007-11-21T20:16:26Z","isPatch":false,"sender":{"key":"jarkao2@o2.pl","avatar":null},"body":"Petr Baudis wrote, On 11/21/2007 04:18 PM:\n\n> On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:\n>> ...\n>> tags\n>> 4 days ago \tv2.6.24-rc3 \tLinux 2.6.24-rc3\n>> 2 weeks ago \tv2.6.24-rc2 \tLinux 2.6.24-rc2\n>> 4 weeks ago \tv2.6.24-rc1 \tLinux 2.6.24-rc1\n>> 6 weeks ago \tv2.6.23 \tLinux 2.6.23\n>>\n>> which drives me crazy, because, without looking at the calendar, and\n>> calculator, I don't really know which month was 6 weeks ago, and 4\n>> days ago, either!\n> \n> I have myself never been sure if the relative times are a good idea or\n> not. :-) Sometimes I hate them, sometimes they are more convenient...\n> \n> At any rate, if you click at the tag name, you should get tag page with\n> full date.\n\n\nSo, it's so easy! Great! It seems I've to get used to this clicking\nmore. It seems I've become too cautious with this, when I've really\n- really, waited after each click there. (I mean a few months ago,\nand my connection was the same; sometimes, one such click took one\nwhole break for coffee.)\n\nI seems, there are simply two kinds of people wrt. calendar/time. I'm\nusually happy if I can figure by myself which day of week is today, but\nI wouldn't even try with something like 4 days ago. But I understand\nI'm not the brightest here...\n\nSo, maybe, some day, with: linux-kernel-for-dummies.org such things\ncould be reconsidered...\n\n> \n>> So, I go to the: http://www.eu.kernel.org/pub/linux/kernel/v2.6/, \n>> do some scrolling, look at this:\n>> ChangeLog-2.6.23 09-Oct-2007 20:38 3.8M \n>>\n>> and only now I can guess, this napi patch didn't manage to 2.6.23.\n>> Of course, usually I've to do a few more clicks and reading to make\n>> sure where it really started.\n>>\n>> So, this could suggest this 2007-10-10 (probably stored with time\n>> too), could be useful here... but it seems, I'm wrong.\n> \n> Yes, there are three scenarios:\n> \n> (i) The patch has been _created_ after the release date. It can't be in\n> the release.\n> (ii) The patch has been created before the release date, but _committed_\n> after the release date. It can't be in the release either.\n> (iii) The patch has been committed before the release date. It _still_\n> might not be in the release if it comes from a different branch.\n> Imagine, say, tglx accepting the patch in his branch, then Linus\n> releasing new kernel version, and only _then_ Linus merging tglx's\n> branch.\n> \n> So the time information isn't really too useful if you want to be any\n> sort of reliable.\n> \n>> Of course, this problem doesn't look so hard if we forget about\n>> git internals: I can imagine keeping a simple database, which\n>> could simply retrieve commit numbers from these ChangeLogs, and\n>> connecting this with gitweb's commit page as well... For\n>> performance reasons, doing it only for stable and testing, so with\n>> -rc 'precision' would be very helpful too.\n> \n> It isn't too hard if we don't forget about git internals either. It's\n> just that getting this information might not be cheap. But maybe I'm\n> wrong and this won't be a problem for sane projects. Someone should post\n> a patch. ;-)\n\n\nIt looks, after Kay's notice, my main problem is solved. And your current\nexplanations are also very precious to me. Probably some things considered\nhere could be done a bit better in the future, but I guess there is enough\nurgent work with git or kernel too, so let's say it's OK for now!\n\nThanks every good git people!\nJarek P.\n\n \n"}]}