On git 1.6 (novice's opinion)

> What I'd like to see in git (My apologies if some were already discussed to 
> death):
> 
> 1) The ability to use the file's time at the time of add/commit instead of
>    the current time, and the ability tho check outfiles with the times stored
>    in the repository.
> 
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
>    but I'd like to have some automatic version numbering keyword at least:
>    Initial idea is that every commit with a change increments the number by
>    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.

> 3) "git undo": If possible undo the effects of the last command.
> 
> Following are some random remarks from a first-time git user, regarding the 
> buld/install:
> 
> Notes on building git-1.6.1.3 on openSUSE 11.0:
> There is no "asciidoc"; the INSTALL should be more verbose on special
> requirements (i.e. additional packages needed, and where to get them).

> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> 
> > What I'd like to see in git (My apologies if some were already discussed to 
> > death):
> > 
> > 1) The ability to use the file's time at the time of add/commit instead of
> >    the current time, and the ability tho check outfiles with the times stored
> >    in the repository.
> > 
> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
> >    but I'd like to have some automatic version numbering keyword at least:
> >    Initial idea is that every commit with a change increments the number by
> >    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
> 
> impossible. Even with checkin- and checkout hooks, you won't get that
> SCCS behaviour. They have to be better in something too :)
> /me still misses that but got used to it

> > 
> > Following are some random remarks from a first-time git user, regarding the 
> > buld/install:
> > 
> > Notes on building git-1.6.1.3 on openSUSE 11.0:
> > There is no "asciidoc"; the INSTALL should be more verbose on special
> > requirements (i.e. additional packages needed, and where to get them).
> 
> # zypper in asciidoc libcurl-devel

>>> 3) "git undo": If possible undo the effects of the last command.
> 
> If impossible, add confirmations for some "dangerous" (non-obvious) commands 
> before doing possibly harmful things. Maybe adding a kind of "user-level setting" 
> (novice, expert, guro) could control such confirmations.
> 

> Ulrich Windl a écrit :
>>>> 3) "git undo": If possible undo the effects of the last command.
>>
>> If impossible, add confirmations for some "dangerous" (non-obvious) 
>> commands before doing possibly harmful things. Maybe adding a kind of 
>> "user-level setting" (novice, expert, guro) could control such 
>> confirmations.
>>
> Why ?

>
> what made me wonder is this (about item 1): I thought I've read that blobs store
> content and attributes, so very obviously I wondered why not store thr "right
> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> test them (which might last several hours or days). The if I'm happy I'll
> "commit".

> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> >
> > what made me wonder is this (about item 1): I thought I've read that blobs store
> > content and attributes, so very obviously I wondered why not store thr "right
> > attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> > test them (which might last several hours or days). The if I'm happy I'll
> > "commit".
> 
> With Git, you usually commit your changes immediately (without waiting
> the result
> of testing), because you can always undo commit until you publish your changes.

> (others may pull it). I don't like publishing my mistakes ;-) Even
> if no-one pulls the commit, your "undo" refers to "committing a fix
> for the last committed mistake", right? Again, I don't really want
> to document/archive (i.e. commit) my mistake. Or did I miss
> something here? 

> AFAIK, "committing" in git is "kind of publishing your work" (others may pull it). 
> I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your 
> "undo" refers to "committing a fix for the last committed mistake", right? Again, 
> I don't really want to document/archive (i.e. commit) my mistake. Or did I miss 
> something here?
> I know: Other's opinions are quite different on these issues.

> Ulrich Windl a écrit :
> > AFAIK, "committing" in git is "kind of publishing your work" (others may pull it). 
> > I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your 
> > "undo" refers to "committing a fix for the last committed mistake", right? Again, 
> > I don't really want to document/archive (i.e. commit) my mistake. Or did I miss 
> > something here?
> > I know: Other's opinions are quite different on these issues.
> 
> commit is local.

> The good way is to commit in your local and private repository.
> Then you can do anything, reset commit you have just done, etc
> When all is ok, you push in a public repository.
> 
> With this workflow, no one see your local work and you can commit very 
> often, undo commit, rebase a lot etc.
> 
> The only result of a such job is a large number of useless objects in 
> your local repository. They will be delete automatically by git, so it's 
> not a problem.
> 
> Regard,
> Etienne

> On 27 Mar 2009 at 14:47, Etienne Vallette d'Osia wrote:
>
>> Ulrich Windl a écrit :
>> > AFAIK, "committing" in git is "kind of publishing your work" (others may pull it). 
>> > I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your 
>> > "undo" refers to "committing a fix for the last committed mistake", right? Again, 
>> > I don't really want to document/archive (i.e. commit) my mistake. Or did I miss 
>> > something here?
>> > I know: Other's opinions are quite different on these issues.
>> 
>> commit is local.
>
> I had made the experience that you can "pull" from a local directory (unless 
> permissions forbid it). As I can't control what others are doing, a "commit" is 
> still more or less making the results public (unless you can convince me that 
> 	I'm wrong). OK, I grew up with servers that host hundreds of users, not with 
> having my own laptop...

> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>
>> what made me wonder is this (about item 1): I thought I've read that blobs store
>> content and attributes, so very obviously I wondered why not store thr "right
>> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
>> test them (which might last several hours or days). The if I'm happy I'll
>> "commit".
>
> With Git, you usually commit your changes immediately (without waiting
> the result
> of testing), because you can always undo commit until you publish your changes.

> Dmitry Potapov <dpotapov@gmail.com> writes:
>
>> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl
>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>>
>>> what made me wonder is this (about item 1): I thought I've read that blobs store
>>> content and attributes, so very obviously I wondered why not store thr "right
>>> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
>>> test them (which might last several hours or days). The if I'm happy I'll
>>> "commit".
>>
>> With Git, you usually commit your changes immediately (without waiting
>> the result
>> of testing), because you can always undo commit until you publish your changes.
>
> Heh, "can" and "usually" are somewhat different.  I don't.

> On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
>
>> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>
>> > What I'd like to see in git (My apologies if some were already discussed to
>> > death):
>> >
>> > 1) The ability to use the file's time at the time of add/commit instead of
>> >    the current time, and the ability tho check outfiles with the times stored
>> >    in the repository.
>> >
>> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
>> >    but I'd like to have some automatic version numbering keyword at least:
>> >    Initial idea is that every commit with a change increments the number by
>> >    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
>>
>> impossible. Even with checkin- and checkout hooks, you won't get that
>> SCCS behaviour. They have to be better in something too :)
>> /me still misses that but got used to it
>
> Hi,
>
> what made me wonder is this (about item 1): I thought I've read that blobs store
> content and attributes, so very obviously I wondered why not store thr "right
> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> test them (which might last several hours or days). The if I'm happy I'll
> "commit". Naturally I want to see the time of change for each file when the change
> had been actually made, not when the change was committed. Likewise when checking
> out, I want to be able to see the time of modification, not the time of commit.
> I'm aware that many people don't care about such differences...
>

> On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> > On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
> >
> >> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
> >> <ulrich.windl@rz.uni-regensburg.de> wrote:
> >>
> >> > What I'd like to see in git (My apologies if some were already discussed to
> >> > death):
> >> >
> >> > 1) The ability to use the file's time at the time of add/commit instead of
> >> >    the current time, and the ability tho check outfiles with the times stored
> >> >    in the repository.
> >> >
> >> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
> >> >    but I'd like to have some automatic version numbering keyword at least:
> >> >    Initial idea is that every commit with a change increments the number by
> >> >    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
> >>
> >> impossible. Even with checkin- and checkout hooks, you won't get that
> >> SCCS behaviour. They have to be better in something too :)
> >> /me still misses that but got used to it
> >
> > Hi,
> >
> > what made me wonder is this (about item 1): I thought I've read that blobs store
> > content and attributes, so very obviously I wondered why not store thr "right
> > attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> > test them (which might last several hours or days). The if I'm happy I'll
> > "commit". Naturally I want to see the time of change for each file when the change
> > had been actually made, not when the change was committed. Likewise when checking
> > out, I want to be able to see the time of modification, not the time of commit.
> > I'm aware that many people don't care about such differences...
> >
> 
> Ok, so if Nancy did some work on the part number form 6 months ago,
> but it got merged into master yesterday. What date should the file
> have? This kind of incremental version number, and trusting of file

> dates really only matters on a centralized system with a single
> branch.
> 
> Not only that, but modification times are much more useful with make.
> Merging or pulling small changes into a tree shouldn't require a full
> rebuild of the entire tree which in some cases could take hours.

> Especially since 'git log <file>', 'gitk <file>', or 'git blame
> <file>' give much more information anyway.
> 
> I know some people sort their directory by date to see what kind of
> stuff happened since they last worked on the repository, but it
> doesn't scale to a project with many directories and the log is much
> more useful anyway.

> On 29 Mar 2009 at 23:18, Russ Dill wrote:
> 
>> On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl
>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>> On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
>>>
>>>> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
>>>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>>>
>>>>> What I'd like to see in git (My apologies if some were already discussed to
>>>>> death):
>>>>>
>>>>> 1) The ability to use the file's time at the time of add/commit instead of
>>>>>    the current time, and the ability tho check outfiles with the times stored
>>>>>    in the repository.
>>>>>
>>>>> 2) Keyword substitution. I know it's controverse (dealing with binary files),
>>>>>    but I'd like to have some automatic version numbering keyword at least:
>>>>>    Initial idea is that every commit with a change increments the number by
>>>>>    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
>>>> impossible. Even with checkin- and checkout hooks, you won't get that
>>>> SCCS behaviour. They have to be better in something too :)
>>>> /me still misses that but got used to it
>>> Hi,
>>>
>>> what made me wonder is this (about item 1): I thought I've read that blobs store
>>> content and attributes, so very obviously I wondered why not store thr "right
>>> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
>>> test them (which might last several hours or days). The if I'm happy I'll
>>> "commit". Naturally I want to see the time of change for each file when the change
>>> had been actually made, not when the change was committed. Likewise when checking
>>> out, I want to be able to see the time of modification, not the time of commit.
>>> I'm aware that many people don't care about such differences...
>>>
>> Ok, so if Nancy did some work on the part number form 6 months ago,
>> but it got merged into master yesterday. What date should the file
>> have? This kind of incremental version number, and trusting of file
> 
> If Nancy committed it with my semantics, the file's date would be 6 months old 
> before the merge. If the merge would not require any change, the file's date would 
> still be six months old. If a change was required, the file's date would be the 
> time of change. That sounds quite logical to me.
> 

>> dates really only matters on a centralized system with a single
>> branch.
>>
>> Not only that, but modification times are much more useful with make.
>> Merging or pulling small changes into a tree shouldn't require a full
>> rebuild of the entire tree which in some cases could take hours.
> 
> Git is not a build system, and I really dislike "full rebuilds", but for 
> stability, before releasing anything, one should test it with a full rebuild.

> >> Not only that, but modification times are much more useful with make.
> >> Merging or pulling small changes into a tree shouldn't require a full
> >> rebuild of the entire tree which in some cases could take hours.
> > 
> > Git is not a build system, and I really dislike "full rebuilds", but for 
> > stability, before releasing anything, one should test it with a full rebuild.
> 
> I build all the time. Before and after every commit (merges are one type of
> commit). I rely on file timestamps to be an accurate indicator of when the
> file last changed *on my disk*.
> 

> On 1 Apr 2009 at 10:37, Andreas Ericsson wrote:
> 
>>>> Not only that, but modification times are much more useful with make.
>>>> Merging or pulling small changes into a tree shouldn't require a full
>>>> rebuild of the entire tree which in some cases could take hours.
>>> Git is not a build system, and I really dislike "full rebuilds", but for 
>>> stability, before releasing anything, one should test it with a full rebuild.
>> I build all the time. Before and after every commit (merges are one type of
>> commit). I rely on file timestamps to be an accurate indicator of when the
>> file last changed *on my disk*.
>>
> 
> But you are silently assuming that the make files are correct: If a file is not 
> being rebuilt, you might be using an old compile without noticing. There a full 
> recompile will at least 1) either trigger an error (missing object file) or 2) 
> build every file. So I really don't see that relying on file dates is much better 
> than doing a full rebuild. That's specifically true if you pull a new tree: If I 
> understand things right, EVERY file will have a current date, so you'll rebuild 
> everything anyway. So you could also have the "real file dates" and then do "make 
> clean; make all". I see no benefit from either approach.
> 

> So I really don't see that relying on file dates is much better than
> doing a full rebuild. That's specifically true if you pull a new tree:
> If I understand things right, EVERY file will have a current date, so
> you'll rebuild everything anyway. So you could also have the "real
> file dates" and then do "make clean; make all". I see no benefit from
> either approach.

>
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.

> On Fri, Mar 27, 2009 at 10:21 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> >
> > 1) The ability to use the file's time at the time of add/commit instead of the
> > current time, and the ability tho check outfiles with the times stored in the
> > repository.
> 
> To check out with the times stored in repository is a a bad idea, because it
> will screw up 'make'.

> 
> >
> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
> > but I'd like to have some automatic version numbering keyword at least:
> > Initial idea is that every commit with a change increments the number by one,
> > and when merging numbers a and b, the resulting number is max(a, b) + 1.
> 
> I am not sure what you want to achieve by having this number. Also, take
> a look at "git describe", it may be close to what you want (or may be not).

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> 
> > I don't understand:
> > If I modify files, then do a make, then do check-in/check-out (and the file times 
> > are unchanged), how would that affect make?
> 
> From "make"'s point of view, chechout is just a modification of the
> file (as any other modification you would do with a text editor). If
> you compile foo.c to foo.o, then checkout another version of foo.c,
> then you want foo.c to be recompiled. If checkout modifies the
> timestamp to pretend it was modified before foo.o, then make thinks
> the file is up to date.
> 
> > If I do an "update/merge from remote" (there is no total ordering of release 
> > numbers anyway) without a "make clean" before, I'm having a problem
> > anyway.
> 
> No, you don't have a problem. Recompiling files after they're modified
> is the job of make, and it just does it. make doesn't know about
> revision numbers or identifiers, just timestamps.

> Hello everybody,
> 
> [About my experience on version control systems: I started out with SCCS in
> the eighties, and I thought it must be cool as the UNIX guys used it to
> maintain their sources. Some times later I was using Emacs' numbered backup
> files as a poor substiutute for nothing else. Then I came across RCS, and I
> liked it soon ,because it was fully documented and well-written. I even ported
> it to MS-DOS (whew!). I was attaching tags to individual files to mark
> "releases" at those times. Then I heard about CVS. It seemed to help with the
> tagging, so I used it for the mopre complex projects. I even did branches and
> merging with it for the Linux sources. I spontaneously diskliked Bitkeeper,
> because it would not work off-line. I heard about Git some time ago, but using
> it seems very non-obvious. After having read the tutorial, and playing some
> simple scenarios, I must admit that I really like the fully distributed nature
> of it. However some commands seem to be a bit strange (e.g. "git add" is
> almost, but quite a "commit" (if you come from CVS)), and sources are quite
> complex. Also some seemingly dangerous commands that cannot easily be undone
> should ask safety questions ("cvs merge (-j)" would also fall into that
> category.]
> 
> What I'd like to see in git (My apologies if some were already discussed to 
> death):
> 
> 1) The ability to use the file's time at the time of add/commit instead of the
> current time, and the ability tho check outfiles with the times stored in the
> repository.
> 
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.

> 3) "git undo": If possible undo the effects of the last command.
> 
> Following are some random remarks from a first-time git user, regarding the 
> buld/install:
> 
> Notes on building git-1.6.1.3 on openSUSE 11.0:
> There is no "asciidoc"; the INSTALL should be more verbose on special
> requirements (i.e. additional packages needed, and where to get them).
> LANG= make configure
> /bin/sh: curl-config: command not found
> make: `configure' is up to date.
> 
> make[2]: Entering directory `/git/git-1.6.1.3'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/git/git-1.6.1.3'
> rm -f git-add.html+ git-add.html
> asciidoc -b xhtml11 -d manpage -f asciidoc.conf \
>                  -agit_version=1.6.1.3 -o git-add.html+ git-add.txt
> make[1]: asciidoc: Command not found
> make[1]: *** [git-add.html] Error 127
> make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'
> make: *** [doc] Error 2
> 
> Some parts of the make process may look like an error if they pass by quickly:
> 
> [...]
>     GEN git-request-pull
>     GEN git-sh-setup
>     GEN git-stash
>     GEN git-submodule
>     GEN git-web--browse
>     SUBDIR perl
> /usr/bin/perl Makefile.PL PREFIX='/home/windl/Projects/git/inst'
> Writing perl.mak for Git
>     GEN git-add--interactive
>     GEN git-archimport
>     GEN git-cvsexportcommit
>     GEN git-cvsimport
> [...]
> 
> Same is true for the install process:
> make[1]: Leaving directory `/home/windl/Projects/git/git-1.6.1.3/git-gui'
> bindir=$(cd '/home/windl/Projects/git/inst/bin' && pwd) && \
>         execdir=$(cd '/home/windl/Projects/git/inst/libexec/git-core/' && pwd) && 
> \
>         { rm -f "$execdir/git-add" && \
>                 ln git-add "$execdir/git-add" 2>/dev/null || \
>                 cp git-add "$execdir/git-add"; } && \
>         {  rm -f "$execdir/git-annotate" && ln "$execdir/git-add" "$execdir/git-
> annotate" 2>/dev/null || ln -s "git-add" "$execdir/git-annotate" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-annotate" || exit;  rm -f "$execdir/git-apply" && 
> ln "$execdir/git-add" "$execdir/git-apply" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-apply" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-apply" || 
> exit;  rm -f "$execdir/git-archive" && ln "$execdir/git-add" "$execdir/git-
> archive" 2>/dev/null || ln -s "git-add" "$execdir/git-archive" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-archive" || exit;  rm -f "$execdir/git-blame" && 
> ln "$execdir/git-add" "$execdir/git-blame" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-blame" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-blame" || 
> exit;  rm -f "$execdir/git-branch" && ln "$execdir/git-add" "$execdir/git-branch" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-branch" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-branch" || exit;  rm -f "$execdir/git-bundle" && 
> ln "$execdir/git-add" "$execdir/git-bundle" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-bundle" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-bundle" 
> || exit;  rm -f "$execdir/git-cat-file" && ln "$execdir/git-add" "$execdir/git-
> cat-file" 2>/dev/null || ln -s "git-add" "$execdir/git-cat-file" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-cat-file" || exit;  rm -f "$execdir/git-check-
> attr" && ln "$execdir/git-add" "$execdir/git-check-attr" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-check-attr" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-check-attr" || exit;  rm -f "$execdir/git-check-ref-format" && ln 
> "$execdir/git-add" "$execdir/git-check-ref-format" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-check-ref-format" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-check-ref-format" || exit;  rm -f "$execdir/git-checkout-index" && 
> ln "$execdir/git-add" "$execdir/git-checkout-index" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-checkout-index" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> checkout-index" || exit;  rm -f "$execdir/git-checkout" && ln "$execdir/git-add" 
> "$execdir/git-checkout" 2>/dev/null || ln -s "git-add" "$execdir/git-checkout" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-checkout" || exit;  rm -f 
> "$execdir/git-clean" && ln "$execdir/git-add" "$execdir/git-clean" 2>/dev/null || 
> ln -s "git-add" "$execdir/git-clean" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-clean" || exit;  rm -f "$execdir/git-clone" && ln "$execdir/git-add" 
> "$execdir/git-clone" 2>/dev/null || ln -s "git-add" "$execdir/git-clone" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-clone" || exit;  rm -f 
> "$execdir/git-commit-tree" && ln "$execdir/git-add" "$execdir/git-commit-tree" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-commit-tree" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-commit-tree" || exit;  rm -f "$execdir/git-
> commit" && ln "$execdir/git-add" "$execdir/git-commit" 2>/dev/null || ln -s "git-
> add" "$execdir/git-commit" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> commit" || exit;  rm -f "$execdir/git-config" && ln "$execdir/git-add" 
> "$execdir/git-config" 2>/dev/null || ln -s "git-add" "$execdir/git-config" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-config" || exit;  rm -f 
> "$execdir/git-count-objects" && ln "$execdir/git-add" "$execdir/git-count-objects" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-count-objects" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-count-objects" || exit;  rm -f "$execdir/git-
> describe" && ln "$execdir/git-add" "$execdir/git-describe" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-describe" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-describe" || exit;  rm -f "$execdir/git-diff-files" && ln 
> "$execdir/git-add" "$execdir/git-diff-files" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-diff-files" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff-
> files" || exit;  rm -f "$execdir/git-diff-index" && ln "$execdir/git-add" 
> "$execdir/git-diff-index" 2>/dev/null || ln -s "git-add" "$execdir/git-diff-index" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff-index" || exit;  rm -f 
> "$execdir/git-diff-tree" && ln "$execdir/git-add" "$execdir/git-diff-tree" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-diff-tree" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-diff-tree" || exit;  rm -f "$execdir/git-diff" && 
> ln "$execdir/git-add" "$execdir/git-diff" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-diff" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff" || 
> exit;  rm -f "$execdir/git-fast-export" && ln "$execdir/git-add" "$execdir/git-
> fast-export" 2>/dev/null || ln -s "git-add" "$execdir/git-fast-export" 2>/dev/null 
> || cp "$execdir/git-add" "$execdir/git-fast-export" || exit;  rm -f "$execdir/git-
> fetch--tool" && ln "$execdir/git-add" "$execdir/git-fetch--tool" 2>/dev/null || ln 
> -s "git-add" "$execdir/git-fetch--tool" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-fetch--tool" || exit;  rm -f "$execdir/git-fetch-pack" && ln 
> "$execdir/git-add" "$execdir/git-fetch-pack" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-fetch-pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> fetch-pack" || exit;  rm -f "$execdir/git-fetch" && ln "$execdir/git-add" 
> "$execdir/git-fetch" 2>/dev/null || ln -s "git-add" "$execdir/git-fetch" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-fetch" || exit;  rm -f 
> "$execdir/git-fmt-merge-msg" && ln "$execdir/git-add" "$execdir/git-fmt-merge-msg" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-fmt-merge-msg" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-fmt-merge-msg" || exit;  rm -f "$execdir/git-for-
> each-ref" && ln "$execdir/git-add" "$execdir/git-for-each-ref" 2>/dev/null || ln -
> s "git-add" "$execdir/git-for-each-ref" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-for-each-ref" || exit;  rm -f "$execdir/git-fsck" && ln 
> "$execdir/git-add" "$execdir/git-fsck" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-fsck" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-fsck" || 
> exit;  rm -f "$execdir/git-gc" && ln "$execdir/git-add" "$execdir/git-gc" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-gc" 2>/dev/null || cp "$execdir/git-
> add" "$execdir/git-gc" || exit;  rm -f "$execdir/git-grep" && ln "$execdir/git-
> add" "$execdir/git-grep" 2>/dev/null || ln -s "git-add" "$execdir/git-grep" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-grep" || exit;  rm -f 
> "$execdir/git-help" && ln "$execdir/git-add" "$execdir/git-help" 2>/dev/null || ln 
> -s "git-add" "$execdir/git-help" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-help" || exit;  rm -f "$execdir/git-init-db" && ln "$execdir/git-
> add" "$execdir/git-init-db" 2>/dev/null || ln -s "git-add" "$execdir/git-init-db" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-init-db" || exit;  rm -f 
> "$execdir/git-log" && ln "$execdir/git-add" "$execdir/git-log" 2>/dev/null || ln -
> s "git-add" "$execdir/git-log" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> log" || exit;  rm -f "$execdir/git-ls-files" && ln "$execdir/git-add" 
> "$execdir/git-ls-files" 2>/dev/null || ln -s "git-add" "$execdir/git-ls-files" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-ls-files" || exit;  rm -f 
> "$execdir/git-ls-remote" && ln "$execdir/git-add" "$execdir/git-ls-remote" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-ls-remote" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-ls-remote" || exit;  rm -f "$execdir/git-ls-tree" 
> && ln "$execdir/git-add" "$execdir/git-ls-tree" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-ls-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-ls-tree" 
> || exit;  rm -f "$execdir/git-mailinfo" && ln "$execdir/git-add" "$execdir/git-
> mailinfo" 2>/dev/null || ln -s "git-add" "$execdir/git-mailinfo" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-mailinfo" || exit;  rm -f "$execdir/git-
> mailsplit" && ln "$execdir/git-add" "$execdir/git-mailsplit" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-mailsplit" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-mailsplit" || exit;  rm -f "$execdir/git-merge" && ln "$execdir/git-
> add" "$execdir/git-merge" 2>/dev/null || ln -s "git-add" "$execdir/git-merge" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge" || exit;  rm -f 
> "$execdir/git-merge-base" && ln "$execdir/git-add" "$execdir/git-merge-base" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-merge-base" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-merge-base" || exit;  rm -f "$execdir/git-merge-
> file" && ln "$execdir/git-add" "$execdir/git-merge-file" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-merge-file" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-merge-file" || exit;  rm -f "$execdir/git-merge-ours" && ln 
> "$execdir/git-add" "$execdir/git-merge-ours" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-merge-ours" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> merge-ours" || exit;  rm -f "$execdir/git-merge-recursive" && ln "$execdir/git-
> add" "$execdir/git-merge-recursive" 2>/dev/null || ln -s "git-add" "$execdir/git-
> merge-recursive" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge-
> recursive" || exit;  rm -f "$execdir/git-mv" && ln "$execdir/git-add" 
> "$execdir/git-mv" 2>/dev/null || ln -s "git-add" "$execdir/git-mv" 2>/dev/null || 
> cp "$execdir/git-add" "$execdir/git-mv" || exit;  rm -f "$execdir/git-name-rev" && 
> ln "$execdir/git-add" "$execdir/git-name-rev" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-name-rev" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-name-
> rev" || exit;  rm -f "$execdir/git-pack-objects" && ln "$execdir/git-add" 
> "$execdir/git-pack-objects" 2>/dev/null || ln -s "git-add" "$execdir/git-pack-
> objects" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-pack-objects" || exit;  
> rm -f "$execdir/git-pack-refs" && ln "$execdir/git-add" "$execdir/git-pack-refs" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-pack-refs" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-pack-refs" || exit;  rm -f "$execdir/git-prune-
> packed" && ln "$execdir/git-add" "$execdir/git-prune-packed" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-prune-packed" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-prune-packed" || exit;  rm -f "$execdir/git-prune" && ln 
> "$execdir/git-add" "$execdir/git-prune" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-prune" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-prune" || 
> exit;  rm -f "$execdir/git-push" && ln "$execdir/git-add" "$execdir/git-push" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-push" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-push" || exit;  rm -f "$execdir/git-read-tree" && 
> ln "$execdir/git-add" "$execdir/git-read-tree" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-read-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-read-
> tree" || exit;  rm -f "$execdir/git-receive-pack" && ln "$execdir/git-add" 
> "$execdir/git-receive-pack" 2>/dev/null || ln -s "git-add" "$execdir/git-receive-
> pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-receive-pack" || exit;  
> rm -f "$execdir/git-reflog" && ln "$execdir/git-add" "$execdir/git-reflog" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-reflog" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-reflog" || exit;  rm -f "$execdir/git-remote" && 
> ln "$execdir/git-add" "$execdir/git-remote" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-remote" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-remote" 
> || exit;  rm -f "$execdir/git-rerere" && ln "$execdir/git-add" "$execdir/git-
> rerere" 2>/dev/null || ln -s "git-add" "$execdir/git-rerere" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-rerere" || exit;  rm -f "$execdir/git-reset" && 
> ln "$execdir/git-add" "$execdir/git-reset" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-reset" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-reset" || 
> exit;  rm -f "$execdir/git-rev-list" && ln "$execdir/git-add" "$execdir/git-rev-
> list" 2>/dev/null || ln -s "git-add" "$execdir/git-rev-list" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-rev-list" || exit;  rm -f "$execdir/git-rev-
> parse" && ln "$execdir/git-add" "$execdir/git-rev-parse" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-rev-parse" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-rev-parse" || exit;  rm -f "$execdir/git-revert" && ln 
> "$execdir/git-add" "$execdir/git-revert" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-revert" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-revert" 
> || exit;  rm -f "$execdir/git-rm" && ln "$execdir/git-add" "$execdir/git-rm" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-rm" 2>/dev/null || cp "$execdir/git-
> add" "$execdir/git-rm" || exit;  rm -f "$execdir/git-send-pack" && ln 
> "$execdir/git-add" "$execdir/git-send-pack" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-send-pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-send-
> pack" || exit;  rm -f "$execdir/git-shortlog" && ln "$execdir/git-add" 
> "$execdir/git-shortlog" 2>/dev/null || ln -s "git-add" "$execdir/git-shortlog" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-shortlog" || exit;  rm -f 
> "$execdir/git-show-branch" && ln "$execdir/git-add" "$execdir/git-show-branch" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-show-branch" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-show-branch" || exit;  rm -f "$execdir/git-show-
> ref" && ln "$execdir/git-add" "$execdir/git-show-ref" 2>/dev/null || ln -s "git-
> add" "$execdir/git-show-ref" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> show-ref" || exit;  rm -f "$execdir/git-stripspace" && ln "$execdir/git-add" 
> "$execdir/git-stripspace" 2>/dev/null || ln -s "git-add" "$execdir/git-stripspace" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-stripspace" || exit;  rm -f 
> "$execdir/git-symbolic-ref" && ln "$execdir/git-add" "$execdir/git-symbolic-ref" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-symbolic-ref" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-symbolic-ref" || exit;  rm -f "$execdir/git-tag" 
> && ln "$execdir/git-add" "$execdir/git-tag" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-tag" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-tag" || 
> exit;  rm -f "$execdir/git-tar-tree" && ln "$execdir/git-add" "$execdir/git-tar-
> tree" 2>/dev/null || ln -s "git-add" "$execdir/git-tar-tree" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-tar-tree" || exit;  rm -f "$execdir/git-unpack-
> objects" && ln "$execdir/git-add" "$execdir/git-unpack-objects" 2>/dev/null || ln 
> -s "git-add" "$execdir/git-unpack-objects" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-unpack-objects" || exit;  rm -f "$execdir/git-update-index" && ln 
> "$execdir/git-add" "$execdir/git-update-index" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-update-index" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> update-index" || exit;  rm -f "$execdir/git-update-ref" && ln "$execdir/git-add" 
> "$execdir/git-update-ref" 2>/dev/null || ln -s "git-add" "$execdir/git-update-ref" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-update-ref" || exit;  rm -f 
> "$execdir/git-upload-archive" && ln "$execdir/git-add" "$execdir/git-upload-
> archive" 2>/dev/null || ln -s "git-add" "$execdir/git-upload-archive" 2>/dev/null 
> || cp "$execdir/git-add" "$execdir/git-upload-archive" || exit;  rm -f 
> "$execdir/git-verify-pack" && ln "$execdir/git-add" "$execdir/git-verify-pack" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-verify-pack" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-verify-pack" || exit;  rm -f "$execdir/git-
> verify-tag" && ln "$execdir/git-add" "$execdir/git-verify-tag" 2>/dev/null || ln -
> s "git-add" "$execdir/git-verify-tag" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-verify-tag" || exit;  rm -f "$execdir/git-write-tree" && ln 
> "$execdir/git-add" "$execdir/git-write-tree" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-write-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> write-tree" || exit;  rm -f "$execdir/git-cherry-pick" && ln "$execdir/git-add" 
> "$execdir/git-cherry-pick" 2>/dev/null || ln -s "git-add" "$execdir/git-cherry-
> pick" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-cherry-pick" || exit;  rm 
> -f "$execdir/git-cherry" && ln "$execdir/git-add" "$execdir/git-cherry" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-cherry" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-cherry" || exit;  rm -f "$execdir/git-format-
> patch" && ln "$execdir/git-add" "$execdir/git-format-patch" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-format-patch" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-format-patch" || exit;  rm -f "$execdir/git-fsck-objects" && ln 
> "$execdir/git-add" "$execdir/git-fsck-objects" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-fsck-objects" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> fsck-objects" || exit;  rm -f "$execdir/git-get-tar-commit-id" && ln 
> "$execdir/git-add" "$execdir/git-get-tar-commit-id" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-get-tar-commit-id" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-get-tar-commit-id" || exit;  rm -f "$execdir/git-init" && ln 
> "$execdir/git-add" "$execdir/git-init" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-init" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-init" || 
> exit;  rm -f "$execdir/git-merge-subtree" && ln "$execdir/git-add" "$execdir/git-
> merge-subtree" 2>/dev/null || ln -s "git-add" "$execdir/git-merge-subtree" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge-subtree" || exit;  rm -f 
> "$execdir/git-peek-remote" && ln "$execdir/git-add" "$execdir/git-peek-remote" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-peek-remote" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-peek-remote" || exit;  rm -f "$execdir/git-repo-
> config" && ln "$execdir/git-add" "$execdir/git-repo-config" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-repo-config" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-repo-config" || exit;  rm -f "$execdir/git-show" && ln 
> "$execdir/git-add" "$execdir/git-show" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-show" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-show" || 
> exit;  rm -f "$execdir/git-stage" && ln "$execdir/git-add" "$execdir/git-stage" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-stage" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-stage" || exit;  rm -f "$execdir/git-status" && 
> ln "$execdir/git-add" "$execdir/git-status" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-status" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-status" 
> || exit;  rm -f "$execdir/git-whatchanged" && ln "$execdir/git-add" "$execdir/git-
> whatchanged" 2>/dev/null || ln -s "git-add" "$execdir/git-whatchanged" 2>/dev/null 
> || cp "$execdir/git-add" "$execdir/git-whatchanged" || exit; } && \
>         ./check_bindir "z$bindir" "z$execdir" "$bindir/git-add"
> 
> There's a problem with "make quick-install-man":
> LANG= make quick-install-man
> make -C Documentation quick-install-man
> make[1]: Entering directory `/git/git-1.6.1.3/Documentation'
> make -C ../ GIT-VERSION-FILE
> make[2]: Entering directory `/git/git-1.6.1.3'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/git/git-1.6.1.3'
> sh ./install-doc-quick.sh origin/man /git/inst/share/man
> ./install-doc-quick.sh: line 9: /git/inst/libexec/git-sh-setup: No such file or 
> directory
> make[1]: *** [quick-install-man] Error 1
> make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'
> make: *** [quick-install-man] Error 2
> 
> Regards,
> Ulrich Windl
> 

> 
> Increasing version numbers are meaningless in a true DVCS world. What is
> your 100th commit may not be someone else's, even if both your master's
> heads are the same! This is why hg version numbers are a local thing.
> They are merely a local shortcut for specifying a revision and serve the
> same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
> work permanently, not even in a local repo, if you allow rebasing.

> On 27 Mar 2009 at 13:49, Michael J Gruber wrote: 
> > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
> 
> [...]
> 
> > Keyword substitution and cvs/svn style version numbers are independent
> > issues. The sha1 describes a commit uniquely, one could use that as a
> > keyword.
> 
> However version numbers and time stamps have the property of being at least 
> partially ordered in respect of "newer/older". That property does not hold for 
> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft 
> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft 
> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)

> 
> > 
> > Increasing version numbers are meaningless in a true DVCS world. What is
> > your 100th commit may not be someone else's, even if both your master's
> > heads are the same! This is why hg version numbers are a local thing.
> > They are merely a local shortcut for specifying a revision and serve the
> > same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
> > work permanently, not even in a local repo, if you allow rebasing.
> 
> Maybe I didn't fully understand, but having a version number that is larger than 
> any parent's version numbers when doing a merge/commit doesn't look wrong to me.

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> > On 27 Mar 2009 at 13:49, Michael J Gruber wrote: 
> > > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
> > 
> > [...]
> > 
> > > Keyword substitution and cvs/svn style version numbers are independent
> > > issues. The sha1 describes a commit uniquely, one could use that as a
> > > keyword.
> > 
> > However version numbers and time stamps have the property of being at least 
> > partially ordered in respect of "newer/older". That property does not hold for 
> > SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft 
> > Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft 
> > Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
> 
> That is why people use output of git-describe and _tag_ their releases,
> and make embedding version number in released version (tarball / binary)
> the job of make: see GIT-VERSION-GEN script in git sources, and how it
> is used in Makefile.

> 
> > 
> > > 
> > > Increasing version numbers are meaningless in a true DVCS world. What is
> > > your 100th commit may not be someone else's, even if both your master's
> > > heads are the same! This is why hg version numbers are a local thing.
> > > They are merely a local shortcut for specifying a revision and serve the
> > > same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
> > > work permanently, not even in a local repo, if you allow rebasing.
> > 
> > Maybe I didn't fully understand, but having a version number that is larger than 
> > any parent's version numbers when doing a merge/commit doesn't look wrong to me.
> 
> I'm sorry to dissapoint you, but without central server assigning
> numbers to commits it wouldn't simply work in distributed version
> control world.  Take for example the following situation: somebody
> clones your repository, and creates new commit on 'master' (trunk) and
> it gets version number N.  Meanwhile you also independently create new
> commit on 'master'... and without central authority it would also get
> version number N.  Then you would merge (pull) his/her changes, and
> you would have two commits with the same number; not something you want.

> 
> Not to mention that you can have multiple roots (multiple commits with
> no parent) in git repository; besides independent branches (like
> 'man', 'html' or 'todo') it is usually result of absorbing or
> subtree-merging other projects.  In 'master' branch there are 5 roots
> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
> and subtree-merged gitk and git-gui.  And here you would again have
> multiple commits with the same number...

> On 27 Mar 2009 at 7:09, Jakub Narebski wrote:
> 
>> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>>> On 27 Mar 2009 at 13:49, Michael J Gruber wrote: 
>>>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>>> [...]
>>>
>>>> Keyword substitution and cvs/svn style version numbers are independent
>>>> issues. The sha1 describes a commit uniquely, one could use that as a
>>>> keyword.
>>> However version numbers and time stamps have the property of being at least 
>>> partially ordered in respect of "newer/older". That property does not hold for 
>>> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft 
>>> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft 
>>> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
>> That is why people use output of git-describe and _tag_ their releases,
>> and make embedding version number in released version (tarball / binary)
>> the job of make: see GIT-VERSION-GEN script in git sources, and how it
>> is used in Makefile.
> 
> OK, but imaginge someone sends you some file that originated from some git 
> version, maybe with minor modifications. Is there a way to find out from what git 
> version that file was derived? IMHO that's where "automatically replaced 
> placeholders" (like $id$) make sense.
> 

>>>> Increasing version numbers are meaningless in a true DVCS world. What is
>>>> your 100th commit may not be someone else's, even if both your master's
>>>> heads are the same! This is why hg version numbers are a local thing.
>>>> They are merely a local shortcut for specifying a revision and serve the
>>>> same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
>>>> work permanently, not even in a local repo, if you allow rebasing.
>>> Maybe I didn't fully understand, but having a version number that is larger than 
>>> any parent's version numbers when doing a merge/commit doesn't look wrong to me.
>> I'm sorry to dissapoint you, but without central server assigning
>> numbers to commits it wouldn't simply work in distributed version
>> control world.  Take for example the following situation: somebody
>> clones your repository, and creates new commit on 'master' (trunk) and
>> it gets version number N.  Meanwhile you also independently create new
>> commit on 'master'... and without central authority it would also get
>> version number N.  Then you would merge (pull) his/her changes, and
>> you would have two commits with the same number; not something you want.
> 
> Anyway the result would have number "N+1". Maybe you misunderstood: I'm not 
> proposing to replace git's internal version numbering (SHA-1), but so introduce 
> some more comprehensible, primitive user-level numbering.
> 

>> Not to mention that you can have multiple roots (multiple commits with
>> no parent) in git repository; besides independent branches (like
>> 'man', 'html' or 'todo') it is usually result of absorbing or
>> subtree-merging other projects.  In 'master' branch there are 5 roots
>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>> and subtree-merged gitk and git-gui.  And here you would again have
>> multiple commits with the same number...
> 
> Which would not harm, because it would be version N from committer X. Any if 
> committer X merges from anything else, the next number would be > N. I did not 
> claim that my method makes a total ordering of commits and merges possible.
> 
> I truly believe in unique IDs, but they are just not handy in every situation.
> 

>> Not to mention that you can have multiple roots (multiple commits with
>> no parent) in git repository; besides independent branches (like
>> 'man', 'html' or 'todo') it is usually result of absorbing or
>> subtree-merging other projects.  In 'master' branch there are 5 roots
>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>> and subtree-merged gitk and git-gui.  And here you would again have
>> multiple commits with the same number...
>
> Which would not harm, because it would be version N from committer X. Any if 
> committer X merges from anything else, the next number would be > N. I did not 
> claim that my method makes a total ordering of commits and merges possible.

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> 
> >> Not to mention that you can have multiple roots (multiple commits with
> >> no parent) in git repository; besides independent branches (like
> >> 'man', 'html' or 'todo') it is usually result of absorbing or
> >> subtree-merging other projects.  In 'master' branch there are 5 roots
> >> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
> >> and subtree-merged gitk and git-gui.  And here you would again have
> >> multiple commits with the same number...
> >
> > Which would not harm, because it would be version N from committer X. Any if 
> > committer X merges from anything else, the next number would be > N. I did not 
> > claim that my method makes a total ordering of commits and merges possible.
> 
> Neither does it make the numbers unique for committer X.
> 
> If commiter X commits a successor to commit N, it's labeled N+1. If
> later, he creates another branch from commit N, and commit, the new,
> other commit will be labeled N+1.

> 
> What can be interesting is that a commit takes 
> max{all commits in repository}+1, not just max{parents} + 1. Then, you
> have local revision numbers, but they're not stable. Indeed, that's
> precisely what Mercurial does.

> 
> But I'm not sure how much simplicity it adds compared to the confusion
> it adds. Newbies will see Mercurial identifiers as
> 
> changeset:   2:699b81a5851b
> changeset:   1:fd4b6597548f
> changeset:   0:58cff172192e
> 
> And think "OK, the revision numbers are 0, 1, 2, and the hexadecimal
> stuff beside is useless". And one day, he'll send a mail, post a
> bugreport, or whatever, saying "I have a problem with revision number
> 42", and no one else but him will know which revision is called "42".
> 
> > I truly believe in unique IDs, but they are just not handy in every situation.
> 
> Usually, people find Git IDs to be non-handy until the find out they
> can cut-and-paste only the first few digits in most cases, like
> 442dd42 instead of 442dd42d6d4903640b0dc5561481a77c88dcea90 ;-).
> 
> -- 
> Matthieu

> On 1 Apr 2009 at 9:54, Matthieu Moy wrote:
> 
>> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>>
>>>> Not to mention that you can have multiple roots (multiple commits with
>>>> no parent) in git repository; besides independent branches (like
>>>> 'man', 'html' or 'todo') it is usually result of absorbing or
>>>> subtree-merging other projects.  In 'master' branch there are 5 roots
>>>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>>>> and subtree-merged gitk and git-gui.  And here you would again have
>>>> multiple commits with the same number...
>>> Which would not harm, because it would be version N from committer X. Any if 
>>> committer X merges from anything else, the next number would be > N. I did not 
>>> claim that my method makes a total ordering of commits and merges possible.
>> Neither does it make the numbers unique for committer X.
>>
>> If commiter X commits a successor to commit N, it's labeled N+1. If
>> later, he creates another branch from commit N, and commit, the new,
>> other commit will be labeled N+1.
> 
> Correct: They live in a parallel universe. But on the long term they will either 
> vanish or be merged in which case the number will be "> N+1" (on the main branch). 
> So we have a branch plus a sequence number all the time.
> 
>> This means even within a repository, you cannot say things like
>> "commit number N", so, OK, you have numerical IDs, but you can't use
>> them.
> 
> I never wanted to have such a thing (using those numbers for commit).
> 

> On 27 Mar 2009 at 7:09, Jakub Narebski wrote:
>> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>>> On 27 Mar 2009 at 13:49, Michael J Gruber wrote: 
>>>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>>> 
>>> [...]
>>> 
>>>> Keyword substitution and cvs/svn style version numbers are independent
>>>> issues. The sha1 describes a commit uniquely, one could use that as a
>>>> keyword.
>>> 
>>> However version numbers and time stamps have the property of being at least 
>>> partially ordered in respect of "newer/older". That property does not hold for 
>>> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft 
>>> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft 
>>> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
>> 
>> That is why people use output of git-describe and _tag_ their releases,
>> and make embedding version number in released version (tarball / binary)
>> the job of make: see GIT-VERSION-GEN script in git sources, and how it
>> is used in Makefile.
> 
> OK, but imaginge someone sends you some file that originated from some git 
> version, maybe with minor modifications. Is there a way to find out from what git 
> version that file was derived? IMHO that's where "automatically replaced 
> placeholders" (like $id$) make sense.

>>>> Increasing version numbers are meaningless in a true DVCS world. What is
>>>> your 100th commit may not be someone else's, even if both your master's
>>>> heads are the same! This is why hg version numbers are a local thing.
>>>> They are merely a local shortcut for specifying a revision and serve the
>>>> same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
>>>> work permanently, not even in a local repo, if you allow rebasing.
>>> 
>>> Maybe I didn't fully understand, but having a version number that is larger than 
>>> any parent's version numbers when doing a merge/commit doesn't look wrong to me.
>> 
>> I'm sorry to dissapoint you, but without central server assigning
>> numbers to commits it wouldn't simply work in distributed version
>> control world.  Take for example the following situation: somebody
>> clones your repository, and creates new commit on 'master' (trunk) and
>> it gets version number N.  Meanwhile you also independently create new
>> commit on 'master'... and without central authority it would also get
>> version number N.  Then you would merge (pull) his/her changes, and
>> you would have two commits with the same number; not something you want.
> 
> Anyway the result would have number "N+1". Maybe you misunderstood: I'm not 
> proposing to replace git's internal version numbering (SHA-1), but so introduce 
> some more comprehensible, primitive user-level numbering.

>> Not to mention that you can have multiple roots (multiple commits with
>> no parent) in git repository; besides independent branches (like
>> 'man', 'html' or 'todo') it is usually result of absorbing or
>> subtree-merging other projects.  In 'master' branch there are 5 roots
>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>> and subtree-merged gitk and git-gui.  And here you would again have
>> multiple commits with the same number...
> 
> Which would not harm, because it would be version N from committer X. Any if 
> committer X merges from anything else, the next number would be> N. I did not 
> claim that my method makes a total ordering of commits and merges possible.
> 
> I truly believe in unique IDs, but they are just not handy in every situation.

> On 27 Mar 2009 at 13:49, Michael J Gruber wrote:
>
>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>
> [...]
>
>> Keyword substitution and cvs/svn style version numbers are independent
>> issues. The sha1 describes a commit uniquely, one could use that as a
>> keyword.
>
> However version numbers and time stamps have the property of being at least
> partially ordered in respect of "newer/older". That property does not hold for
> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft
> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft
> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> 
> > ... Also some seemingly dangerous commands that cannot easily be undone
> > should ask safety questions ("cvs merge (-j)" would also fall into that
> > category.
> 
> This is slightly an interesting point.
> 
> In CVS and Subversion, "merge" (rather "update") can be a dangerous
> operation.  You start working, you keep building, and you eventually
> accumulate quite a lot of changes but you still cannot see the end of the
> tunnel.  Your changes are incomplete and you will upset others if you
> commit.  Your changes are extensive enough that it can conflict heavily
> with what others have done already, and there is a high chance that you
> can screw up the merging but there is no easy way (unless you tar-up the
> whole work tree before attempting to update) to get back to the state
> before your merge.  Damned if you commit, damned if you don't.  You lose
> either way.
> 
> This is because you cannot have a local commit.  The problem is inherent
> to the centralized nature of these systems.
> 
> Distributed systems are different.  Unlike CVS/Subversion's
> 
> 	work work work; then
> 
>         update to merge, risk screwing up the work in progress (or almost
> 	finished work); then
> 
>         commit
> 
> workflow, in a distributed system, you first commit and then merge,
> preferably from a clean slate.  You will not have to worry about screwing
> up the conflict resolution, because both states (what the other guy did,
> and what you did) are committed safely away and you can reset back to the
> state before you start your merge.

> On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> 
> > 3) "git undo": If possible undo the effects of the last command.
> 
> You can roll back the state of most local references by using the git 
> reflog (see git reflog --help for more information). This covers most 
> situations - but note that it only works to roll back to a committed 
> state, and won't save any uncommitted data at all.

> Hi,
> 
> On Sun, 29 Mar 2009, Bryan Donlan wrote:
> 
> > On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl
> > <ulrich.windl@rz.uni-regensburg.de> wrote:
> > 
> > > 3) "git undo": If possible undo the effects of the last command.
> > 
> > You can roll back the state of most local references by using the git 
> > reflog (see git reflog --help for more information). This covers most 
> > situations - but note that it only works to roll back to a committed 
> > state, and won't save any uncommitted data at all.
> 
> Which is why you should commit early and often, and certainly before doing 
> something bigger.

> On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> 
> 
> > 3) "git undo": If possible undo the effects of the last command.
> 
> You can roll back the state of most local references by using the git
> reflog (see git reflog --help for more information). This covers most
> situations - but note that it only works to roll back to a committed
> state, and won't save any uncommitted data at all.

> 
> 1) The ability to use the file's time at the time of add/commit instead of the
> current time, and the ability tho check outfiles with the times stored in the
> repository.
> 

> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.
> 

> 
> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
> number from the git tag (releases can only be built from signed tags), and
> it updates macros and whatnot used for informing the user which version he
> or she is running. This makes a lot more sense both from a bug-reporting
> and from a release process view than having generated version-numbers in

> files. On a side-note; When I told my co-workers I'd like us to switch to
> git, two of them asked about autoversioning features. I said there weren't
> any and asked them to name a single time when we've actually used them for
> anything *at all*. In a team of eight, having been programming for three
> years with 12 releases and about 800 bugreports + feature-requests, noone
> could mention a single time when the autogenerated version numbers had
> actually been used for anything.

> On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
> 
> [...]
>> 3 It's far better to set the version number in the release-process. Usually
>>   this can be done automatically by one invocation of "git describe", just
>>   as git.git does it.
> 
> However if you put a version number into every file and THEN commit, it's somewhat 
> ridiculous (I'll have to learn about "git describe"). But for configuration 
> management you want to have exactly that (find exactly the file that was shipped 
> (or used to build)).
> 
>> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
>> number from the git tag (releases can only be built from signed tags), and
>> it updates macros and whatnot used for informing the user which version he
>> or she is running. This makes a lot more sense both from a bug-reporting
>> and from a release process view than having generated version-numbers in
> 
> So your "release commits" are outside GIT? (see above)
> 

>> files. On a side-note; When I told my co-workers I'd like us to switch to
>> git, two of them asked about autoversioning features. I said there weren't
>> any and asked them to name a single time when we've actually used them for
>> anything *at all*. In a team of eight, having been programming for three
>> years with 12 releases and about 800 bugreports + feature-requests, noone
>> could mention a single time when the autogenerated version numbers had
>> actually been used for anything.
> 
> Hmm: Were they visible to customers?
> 

>> Otoh, having the entire repository locally makes it painless to view the
>> commit-log for an entire project (or parts of it) and see who changed what
>> when and why, which is information that's actually *useful*.
> 
> [Big meals need time to digest: Just give me more time to do so (getting into 
> git). As with vi and Emacs (usualy I prefer Emacs), there will be situations when 
> I won't use Git however]
> 

> Ulrich Windl wrote:
> > On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
> > 
> > [...]
> >> 3 It's far better to set the version number in the release-process. Usually
> >>   this can be done automatically by one invocation of "git describe", just
> >>   as git.git does it.
> > 
> > However if you put a version number into every file and THEN commit, it's somewhat 
> > ridiculous (I'll have to learn about "git describe"). But for configuration 
> > management you want to have exactly that (find exactly the file that was shipped 
> > (or used to build)).
> > 
> >> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
> >> number from the git tag (releases can only be built from signed tags), and
> >> it updates macros and whatnot used for informing the user which version he
> >> or she is running. This makes a lot more sense both from a bug-reporting
> >> and from a release process view than having generated version-numbers in
> > 
> > So your "release commits" are outside GIT? (see above)
> > 
> 
> They aren't release commits. Just a script that creates a tarball and an RPM
> (in our case).

> 
> >> files. On a side-note; When I told my co-workers I'd like us to switch to
> >> git, two of them asked about autoversioning features. I said there weren't
> >> any and asked them to name a single time when we've actually used them for
> >> anything *at all*. In a team of eight, having been programming for three
> >> years with 12 releases and about 800 bugreports + feature-requests, noone
> >> could mention a single time when the autogenerated version numbers had
> >> actually been used for anything.
> > 
> > Hmm: Were they visible to customers?
> > 
> 
> Ofcourse they were, but they were rather useless even there, as a customer
> could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot
> of confusion for our not-so-techsavvy users and customers.

> On 1 Apr 2009 at 10:41, Andreas Ericsson wrote:
> 
>> Ulrich Windl wrote:
>>> On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
>>>
>>> [...]
>>>> 3 It's far better to set the version number in the release-process. Usually
>>>>   this can be done automatically by one invocation of "git describe", just
>>>>   as git.git does it.
>>> However if you put a version number into every file and THEN commit, it's somewhat 
>>> ridiculous (I'll have to learn about "git describe"). But for configuration 
>>> management you want to have exactly that (find exactly the file that was shipped 
>>> (or used to build)).
>>>
>>>> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
>>>> number from the git tag (releases can only be built from signed tags), and
>>>> it updates macros and whatnot used for informing the user which version he
>>>> or she is running. This makes a lot more sense both from a bug-reporting
>>>> and from a release process view than having generated version-numbers in
>>> So your "release commits" are outside GIT? (see above)
>>>
>> They aren't release commits. Just a script that creates a tarball and an RPM
>> (in our case).
> 
> OK, that's what I did with CVS also, but with "CVS diff" I see the revision 
> numbers (old and new) for every single file in a patch, while Git just uses "a" 
> and "b". There I'd still prefer what CVS does.
> 
>>>> files. On a side-note; When I told my co-workers I'd like us to switch to
>>>> git, two of them asked about autoversioning features. I said there weren't
>>>> any and asked them to name a single time when we've actually used them for
>>>> anything *at all*. In a team of eight, having been programming for three
>>>> years with 12 releases and about 800 bugreports + feature-requests, noone
>>>> could mention a single time when the autogenerated version numbers had
>>>> actually been used for anything.
>>> Hmm: Were they visible to customers?
>>>
>> Ofcourse they were, but they were rather useless even there, as a customer
>> could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot
>> of confusion for our not-so-techsavvy users and customers.
> 
> What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? 
> Because it's a manual process?
> 

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

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