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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
