Re: update @version in file

From: Jakub Narebski <jnareb@gmail.com>
Date: May 13, 2009, 09:42 UTC
Message-ID: <m3iqk5l4ps.fsf@localhost.localdomain>
In-Reply-To: <4A0A8ED8.8000905@op5.se>

Andreas Ericsson <ae@op5.se> writes:

> takeshin wrote:

Show 19 quoted lines

> > Hi,
> > I have following PHPDoc code in files of my repository:
> > /**
> >  * Class description
> >  * @version 1.2
> >  */
> >  class Name…
> > Is there a chance that git could increment this @version
> > automatically
> > on each commit
> 
> 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.
> 
> > or stamp the file somehow?
> >
> 
> Yes. It can only do so using the blob id though.

See documentation of `ident` attribute in gitattributes(5) manpage.

Well, you can always use `export-subst` gitattribute to make git-archive do keyword expansion, and there you can use things like date or decoration (tag / version).

Show 11 quoted lines

> Things like this can be done in CVS and Subversion because
> a) CVS and SVN are file-based. The version they write are not the
>    version of the *project*, but the version of the file (not even
>    remotely the same thing).
> b) they do not really support proper branching.
> 
> In git (which is snapshot based and supports branching very well indeed),
> it *could* be done, but it would incur such an enormous performance
> penalty when switching branches, creating a new commit or re-writing
> history (since every file would have to be altered) that it's never
> been considered worth adding.

You can cobble something together using "smudge" (to do keyword expansion) and "clean" (to store files with keywords not expanded in git repository) filters, see `filter` attribute in gitattributes(5). But I am not sure it is worth it.

HTH

-- 
Jakub Narebski
Poland
ShadeHawk on #git