Re: update @version in file

On Wed, 13 May 2009, Dan Loewenherz wrote:

On 13/05/09 02:42 -0700, Jakub Narebski wrote:

quoted

Andreas Ericsson [off-list ref] writes:

quoted

quoted

No, but see GIT-VERSION-GEN and "git help describe" for info on how to
replace such version tags using a script when you cut a release of your
project.

Couldn't Git be a little more friendly? 

No, Git cannot have that feature.

You can choose to ignore an uncommitted file through the `git update-index 
--assume-unchanged` command. But AFAIK, Git doesn't allow one to ignore 
uncommitted _lines_ in tracked files. If this feature were implemented, a 
post commit hook could write in the latest commit hash and git wouldn't care.

No, I am afraid it is not possible. Let me explain

1. Git doesn't touch files which didn't change during rewinding (going
   back in history, perhaps to start development of maintenance branch,
   or doing bisection of history to find commit which introduced a bug),
   and when switching branches. If keyword expansion was about *commit*
   information (like description/decoration e.g. 'v1.6.3-17-g35805ce',
   or author, or change date) then when switching branches (going to
   other commit, with other info) you would have to rewrite all files.
   This would very badly affect performance. Also, when committing you
   would have to rewrite all files.

2. If you wanted however to have *file* version (like in CVS), then it
   is impossible because Git doesn't store such info (well, beside
   blob id of a contents of a file, but that is not exactly a version
   number); moreover it doesn't make much sense to know such number.
   It is next to useless; it is changesets that matter. CVS has it
   because it evolved from file-based version control system, only
   cobbled together.
 

Is this something that is worth pursuing?

You can write your own clear/smudge filters if you are stubborn
about having version info in files which are under version control
(and you can ask SCM at which version you are), rather than adding
version info on release (so the program can support --version option).
-- 
Jakub Narebski
Poland