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 or stamp the file somehow?
I'm using git on Windows.
--
regards
takeshin
--
View this message in context: http://n2.nabble.com/update-%40version-in-file-tp2879913p2879913.html
Sent from the git mailing list archive at Nabble.com.
takeshin wrote:
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. 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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
http://nordicmeetonnagios.op5.org/
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
Andreas Ericsson [off-list ref] writes:
takeshin wrote:
quoted
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.
quoted
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).
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
On 13/05/09 02:42 -0700, Jakub Narebski wrote:
Andreas Ericsson [off-list ref] writes:
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?
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.
Is this something that is worth pursuing?
Dan
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