Re: update @version in file

[Jakub Narebski <jnareb@gmail.com>]

On Wed, 13 May 2009, Matthieu Moy napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > 2. If you wanted however to have *file* version (like in CVS), then it
> >    is impossible because Git doesn't store such info
> 
> What could make sense is the commit id where the file was last
> modified (i.e. the first item that appears when one runs "git log" on
> the file). Not exactly as simple as it could be because of merge, but
> not completely meaningless either.

First, while it quite neatly solves the problem of cost of commit (only
changed files needs to have keyword expansion updated), it is also much
more costly (possibly much, much more, especially as Andreas wrote for
files which change rarely) than commit info based keywords (like those
`export-subst` keywords).  Note that Git doesn't store per-file version
info.

Second, you are mistaken thinking that 'commit id where the file was
last modified' is a file-level variable.  It is not, because file could
have arrived independently at given contents (e.g. by cherry-picking
bugfix, or by reverting some change one one branch while other is from
before a change).  See for example sample history below


   .---.---.---a--.---b---.---c     <--- branch_1
                \
                 \--.---d---c'      <--- branch_2

where given file is at the same version (has the same contents) in both
"c" and "c'" commits, but for one 'last changed' would be "b", for other
it would be "d".

This means that not only rewinding is costly (as per previous point), but
also switching branches is costly; you have to get history for each and
every file, even if they didn't change in the switch.

Third, files in project are not independent. Last commit the file was
changed doesn't give us much informational value, I don't think. Well,
at least not as keyword expansion; you might want to ask your SCM about
this info.  Whole project tags means that you can get to exact version
you stated.  "File history" revision numbers would not.


I don't know why you need such keyword. Users either browse files via SCM
(where they have access to SCM to get such info, or browse files from
tarball, where project revision is embedded (substituted by Makefile)...

-- 
Jakub Narebski
Poland