Re: update @version in file

From: Jakub Narebski <jnareb@gmail.com>
Date: May 13, 2009, 23:02 UTC
Message-ID: <200905140102.15578.jnareb@gmail.com>
In-Reply-To: <vpqeiutrl09.fsf@bauges.imag.fr>

On Wed, 13 May 2009, Matthieu Moy napisał:

Show 9 quoted lines

> 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