From: Andreas Ericsson <exon@op5.com>
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: Andreas Ericsson <exon@op5.com>, Andreas Ericsson <ae@op5.se>,
git@vger.kernel.org
Subject: Re: On git 1.6 (novice's opinion)
Date: Wed, 01 Apr 2009 14:40:30 +0200 [thread overview]
Message-ID: <49D360BE.6030100@op5.com> (raw)
In-Reply-To: <49D37190.23422.145597D@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
> On 1 Apr 2009 at 12:21, Andreas Ericsson wrote:
>
> [...]
>>> What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade?
>>> Because it's a manual process?
>>>
>> It MAY not get updated, since $Id$ tags are per-file instead of per-project.
>> Any sane project will have more than one file, and the file listing the
>> $Id$ that the end-user sees may not have changed since the last release.
>>
>> Per-file revision tags are stupid and useless for anything but a one-file
>> project.
>
> Hmm...:
> # what vmunix
> vmunix:
> ivt.s $Date: 2008/11/21 09:10:19 $Revision: r11.31/5 PATCH_11.31 (B11.3
> 1.0903LR)
> side_dumpdev - HP IDE Dump Driver B.11.31 /ux/core/kern/em/svc/dump/scs
> i_ide_dumpdev.c: Jan 8 2009, 23:48:25
> eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
> /eschgr.c:Jan 10 2007,17:04:47
> eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
> /eschgr_diag.c:Dec 27 2006,16:59:17
> [...]
> vxfs:$RCSfile: vx_portal.c,v $ $Revision: 4.14.26.3 $
> vxfs:$RCSfile: vx_portal_osrel.c,v $ $Revision: 1.1.2.1 $
> vxfs:$RCSfile: vx_portal_dlkm.c,v $ $Revision: 1.1.2.1 $
> vxfs:$RCSfile: vxportal50.modmeta,v $ $Revision: 1.1.2.5 $
> wsio_cdio.c $Date: 2008/06/03 05:52:50 $Revision: r11.31/13 PATCH_11.31
> (B11.31.0809LR)
> $Revision: wsio: B11.31.0809LR
> $Revision: wxb_hp: B.11.31_LR
> tracer.s $Date: 2008/04/28 17:14:06 $Revision: r11.31/3 PATCH_11.31 (B1
> 1.31.0809LR)
>
> For a kernel, where development is decentralized, it would make sense: Imageine a
> user (or distributor) will nut upgrade anything to the latest version, but only
> parts (subsystems). Then the single kernel version number is meaningless.
>
Not really. They can (and should) create their own version numbers. I can't make
sense of the above output. If you ask a developer to piece together the puzzle
that makes up this subsystem and then fit it into the bigger picture, he won't
love you for it. Not only because this particular subsystem might well be the
same version across several different releases with all their different API's
(the input system has changed its API's incompatibly quite frequently over the
last six months, fe, so a driver-version *alone* in that system makes absolutely
no sense if you're trying to debug it).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
next prev parent reply other threads:[~2009-04-01 12:42 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-27 7:21 On git 1.6 (novice's opinion) Ulrich Windl
2009-03-27 8:05 ` H.Merijn Brand
2009-03-27 9:50 ` Ulrich Windl
2009-03-27 10:57 ` Etienne Vallette d'Osia
2009-03-27 11:30 ` Etienne Vallette d'Osia
2009-03-27 12:24 ` Dmitry Potapov
2009-03-27 13:39 ` Ulrich Windl
2009-03-27 13:45 ` Matthieu Moy
2009-03-27 13:47 ` Etienne Vallette d'Osia
2009-04-01 6:50 ` Ulrich Windl
2009-04-01 7:41 ` Matthieu Moy
2009-03-28 1:30 ` Junio C Hamano
2009-03-28 1:30 ` Junio C Hamano
2009-03-28 9:53 ` Dmitry Potapov
2009-03-30 6:18 ` Russ Dill
2009-04-01 7:53 ` Ulrich Windl
2009-04-01 8:37 ` Andreas Ericsson
2009-04-01 9:47 ` Ulrich Windl
2009-04-01 10:17 ` Andreas Ericsson
2009-04-01 20:37 ` Heiko Voigt
2009-03-27 12:24 ` Dmitry Potapov
2009-03-27 13:35 ` Ulrich Windl
2009-03-27 13:44 ` Matthieu Moy
2009-04-01 6:45 ` Ulrich Windl
2009-04-01 7:42 ` Matthieu Moy
2009-03-27 12:49 ` Michael J Gruber
2009-03-27 13:48 ` Ulrich Windl
2009-03-27 14:09 ` Jakub Narebski
2009-04-01 6:59 ` Ulrich Windl
2009-04-01 7:29 ` Andreas Ericsson
2009-04-01 7:54 ` Matthieu Moy
2009-04-01 9:38 ` Ulrich Windl
2009-04-01 10:10 ` Andreas Ericsson
2009-04-02 2:17 ` Jakub Narebski
2009-03-28 10:33 ` demerphq
2009-03-28 1:30 ` Junio C Hamano
2009-04-01 7:35 ` Ulrich Windl
2009-03-29 5:41 ` Bryan Donlan
2009-03-29 9:50 ` Johannes Schindelin
2009-04-01 7:42 ` Ulrich Windl
2009-04-01 7:40 ` Ulrich Windl
2009-03-30 9:06 ` Andreas Ericsson
2009-04-01 8:15 ` Ulrich Windl
2009-04-01 8:41 ` Andreas Ericsson
2009-04-01 9:55 ` Ulrich Windl
2009-04-01 10:21 ` Andreas Ericsson
2009-04-01 11:52 ` Ulrich Windl
2009-04-01 12:40 ` Andreas Ericsson [this message]
2009-04-01 2:32 ` Kris Shannon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49D360BE.6030100@op5.com \
--to=exon@op5.com \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=ulrich.windl@rz.uni-regensburg.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).