{"thread":{"id":"19334","subject":"update @version in file","startedAt":"2009-05-13T08:59:50Z","lastAt":"2009-05-14T07:08:05Z","messageCount":10,"participants":["takeshin","Andreas Ericsson","Jakub Narebski","Dan Loewenherz","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113746","messageId":"1242205190383-2879913.post@n2.nabble.com","threadId":"19334","inReplyTo":null,"subject":"update @version in file","fromName":"takeshin","fromEmail":"admirau@gmail.com","sentAt":"2009-05-13T08:59:50Z","receivedAt":"2009-05-13T08:59:50Z","isPatch":false,"sender":{"key":"admirau@gmail.com","avatar":null},"body":"\nHi,\n\nI have following PHPDoc code in files of my repository:\n\n/**\n * Class description\n * @version 1.2\n */\n class Name…\n\nIs there a chance that git could increment this @version automatically\non each commit or stamp the file somehow?\n\nI'm using git on Windows.\n\n-- \nregards\ntakeshin\n\n\n-- \nView this message in context: http://n2.nabble.com/update-%40version-in-file-tp2879913p2879913.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"113749","messageId":"4A0A8ED8.8000905@op5.se","threadId":"19334","inReplyTo":"1242205190383-2879913.post@n2.nabble.com","subject":"Re: update @version in file","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-05-13T09:11:52Z","receivedAt":"2009-05-13T09:11:52Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"takeshin wrote:\n> Hi,\n> \n> I have following PHPDoc code in files of my repository:\n> \n> /**\n> * Class description\n> * @version 1.2\n> */\n> class Name…\n> \n> Is there a chance that git could increment this @version automatically\n> on each commit\n\nNo, but see GIT-VERSION-GEN and \"git help describe\" for info on how to\nreplace such version tags using a script when you cut a release of your\nproject.\n\n> or stamp the file somehow?\n> \n\nYes. It can only do so using the blob id though. Things like this can\nbe done in CVS and Subversion because\na) CVS and SVN are file-based. The version they write are not the\n version of the *project*, but the version of the file (not even\n remotely the same thing).\nb) they do not really support proper branching.\n\nIn git (which is snapshot based and supports branching very well indeed),\nit *could* be done, but it would incur such an enormous performance\npenalty when switching branches, creating a new commit or re-writing\nhistory (since every file would have to be altered) that it's never\nbeen considered worth adding.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nRegister now for Nordic Meet on Nagios, June 3-4 in Stockholm\n http://nordicmeetonnagios.op5.org/\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"113750","messageId":"1242206566420-2880239.post@n2.nabble.com","threadId":"19334","inReplyTo":"4A0A8ED8.8000905@op5.se","subject":"Re: update @version in file","fromName":"takeshin","fromEmail":"admirau@gmail.com","sentAt":"2009-05-13T09:22:46Z","receivedAt":"2009-05-13T09:22:46Z","isPatch":false,"sender":{"key":"admirau@gmail.com","avatar":null},"body":"\nThank you for such a quick and comprehensive answer.\n\n-- \nregards\ntakeshin\n\n\n-- \nView this message in context: http://n2.nabble.com/update-%40version-in-file-tp2879913p2880239.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"113753","messageId":"m3iqk5l4ps.fsf@localhost.localdomain","threadId":"19334","inReplyTo":"4A0A8ED8.8000905@op5.se","subject":"Re: update @version in file","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-13T09:42:06Z","receivedAt":"2009-05-13T09:42:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson writes:\n> takeshin wrote:\n\n> > Hi,\n> > I have following PHPDoc code in files of my repository:\n> > /**\n> > * Class description\n> > * @version 1.2\n> > */\n> > class Name…\n> > Is there a chance that git could increment this @version\n> > automatically\n> > on each commit\n> \n> No, but see GIT-VERSION-GEN and \"git help describe\" for info on how to\n> replace such version tags using a script when you cut a release of your\n> project.\n> \n> > or stamp the file somehow?\n> >\n> \n> Yes. It can only do so using the blob id though. \n\nSee documentation of `ident` attribute in gitattributes(5) manpage.\n\nWell, you can always use `export-subst` gitattribute to make\ngit-archive do keyword expansion, and there you can use things like\ndate or decoration (tag / version).\n\n> Things like this can be done in CVS and Subversion because\n> a) CVS and SVN are file-based. The version they write are not the\n> version of the *project*, but the version of the file (not even\n> remotely the same thing).\n> b) they do not really support proper branching.\n> \n> In git (which is snapshot based and supports branching very well indeed),\n> it *could* be done, but it would incur such an enormous performance\n> penalty when switching branches, creating a new commit or re-writing\n> history (since every file would have to be altered) that it's never\n> been considered worth adding.\n\nYou can cobble something together using \"smudge\" (to do keyword\nexpansion) and \"clean\" (to store files with keywords not expanded in\ngit repository) filters, see `filter` attribute in gitattributes(5).\nBut I am not sure it is worth it.\n\nHTH\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"113798","messageId":"20090513160415.GA4097@andros.launchmodem.com","threadId":"19334","inReplyTo":"m3iqk5l4ps.fsf@localhost.localdomain","subject":"Re: update @version in file","fromName":"Dan Loewenherz","fromEmail":"dloewenherz@gmail.com","sentAt":"2009-05-13T16:04:15Z","receivedAt":"2009-05-13T16:04:15Z","isPatch":false,"sender":{"key":"dloewenherz@gmail.com","avatar":"https://gravatar.com/avatar/69134b10dc6663fd8a4ac95edc0e556662c43c3acb226cec9f697cb8848198b2?d=mp&s=160"},"body":"\nOn 13/05/09 02:42 -0700, Jakub Narebski wrote:\n> Andreas Ericsson writes:\n> > No, but see GIT-VERSION-GEN and \"git help describe\" for info on how to\n> > replace such version tags using a script when you cut a release of your\n> > project.\n\nCouldn't Git be a little more friendly? \n\nYou can choose to ignore an uncommitted file through the `git update-index \n--assume-unchanged` command. But AFAIK, Git doesn't allow one to ignore \nuncommitted _lines_ in tracked files. If this feature were implemented, a \npost commit hook could write in the latest commit hash and git wouldn't care.\n\nIs this something that is worth pursuing?\n\n Dan\n"},{"id":"113804","messageId":"200905131856.46344.jnareb@gmail.com","threadId":"19334","inReplyTo":"20090513160415.GA4097@andros.launchmodem.com","subject":"Re: update @version in file","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-13T16:56:44Z","receivedAt":"2009-05-13T16:56:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 13 May 2009, Dan Loewenherz wrote:\n> On 13/05/09 02:42 -0700, Jakub Narebski wrote:\n> > Andreas Ericsson writes:\n\n> > > No, but see GIT-VERSION-GEN and \"git help describe\" for info on how to\n> > > replace such version tags using a script when you cut a release of your\n> > > project.\n> \n> Couldn't Git be a little more friendly? \n\nNo, Git cannot have that feature.\n\n> You can choose to ignore an uncommitted file through the `git update-index \n> --assume-unchanged` command. But AFAIK, Git doesn't allow one to ignore \n> uncommitted _lines_ in tracked files. If this feature were implemented, a \n> post commit hook could write in the latest commit hash and git wouldn't care.\n\nNo, I am afraid it is not possible. Let me explain\n\n1. Git doesn't touch files which didn't change during rewinding (going\n back in history, perhaps to start development of maintenance branch,\n or doing bisection of history to find commit which introduced a bug),\n and when switching branches. If keyword expansion was about *commit*\n information (like description/decoration e.g. 'v1.6.3-17-g35805ce',\n or author, or change date) then when switching branches (going to\n other commit, with other info) you would have to rewrite all files.\n This would very badly affect performance. Also, when committing you\n would have to rewrite all files.\n\n2. If you wanted however to have *file* version (like in CVS), then it\n is impossible because Git doesn't store such info (well, beside\n blob id of a contents of a file, but that is not exactly a version\n number); moreover it doesn't make much sense to know such number.\n It is next to useless; it is changesets that matter. CVS has it\n because it evolved from file-based version control system, only\n cobbled together.\n \n> Is this something that is worth pursuing?\n\nYou can write your own clear/smudge filters if you are stubborn\nabout having version info in files which are under version control\n(and you can ask SCM at which version you are), rather than adding\nversion info on release (so the program can support --version option).\n-- \nJakub Narebski\nPoland\n"},{"id":"113806","messageId":"vpqeiutrl09.fsf@bauges.imag.fr","threadId":"19334","inReplyTo":"200905131856.46344.jnareb@gmail.com","subject":"Re: update @version in file","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-05-13T17:05:42Z","receivedAt":"2009-05-13T17:05:42Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> 2. If you wanted however to have *file* version (like in CVS), then it\n> is impossible because Git doesn't store such info\n\nWhat could make sense is the commit id where the file was last\nmodified (i.e. the first item that appears when one runs \"git log\" on\nthe file). Not exactly as simple as it could be because of merge, but\nnot completely meaningless either.\n\n-- \nMatthieu\n"},{"id":"113813","messageId":"4A0B059F.1020509@op5.se","threadId":"19334","inReplyTo":"vpqeiutrl09.fsf@bauges.imag.fr","subject":"Re: update @version in file","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-05-13T17:38:39Z","receivedAt":"2009-05-13T17:38:39Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthieu Moy wrote:\n> Jakub Narebski writes:\n> \n>> 2. If you wanted however to have *file* version (like in CVS), then it\n>> is impossible because Git doesn't store such info\n> \n> What could make sense is the commit id where the file was last\n> modified (i.e. the first item that appears when one runs \"git log\" on\n> the file). Not exactly as simple as it could be because of merge, but\n> not completely meaningless either.\n> \n\nThat would also incur an impossible performance penalty. A *LOT* of\nprojects have a LICENSE file that hasn't been changed since the project\nwas put under version control in the first place. Is git suppose to\ndig through history for every revision just to make sure that the\nLICENSE file hasn't been changed since 1999?\n\nNow think about such a feature for a project with 20k+ files (not even\nvery large, as projects go) and see how much time you lose when\nswitching branches. Then ask yourself: What's more important: Developer\ntime or version numbers in files that can be hacked in to match the\nentire project's version when releasing?\n\n100% of all discussions about this on git@vger has ended up with the\nconclusion that it's not worth wasting a couple of seconds of a\ndeveloper's time for this feature to exist. That's why this feature\ndoesn't exist in git yet.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nRegister now for Nordic Meet on Nagios, June 3-4 in Stockholm\n http://nordicmeetonnagios.op5.org/\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"113857","messageId":"200905140102.15578.jnareb@gmail.com","threadId":"19334","inReplyTo":"vpqeiutrl09.fsf@bauges.imag.fr","subject":"Re: update @version in file","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-13T23:02:14Z","receivedAt":"2009-05-13T23:02:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 13 May 2009, Matthieu Moy napisał:\n> Jakub Narebski writes:\n> \n> > 2. If you wanted however to have *file* version (like in CVS), then it\n> > is impossible because Git doesn't store such info\n> \n> What could make sense is the commit id where the file was last\n> modified (i.e. the first item that appears when one runs \"git log\" on\n> the file). Not exactly as simple as it could be because of merge, but\n> not completely meaningless either.\n\nFirst, while it quite neatly solves the problem of cost of commit (only\nchanged files needs to have keyword expansion updated), it is also much\nmore costly (possibly much, much more, especially as Andreas wrote for\nfiles which change rarely) than commit info based keywords (like those\n`export-subst` keywords). Note that Git doesn't store per-file version\ninfo.\n\nSecond, you are mistaken thinking that 'commit id where the file was\nlast modified' is a file-level variable. It is not, because file could\nhave arrived independently at given contents (e.g. by cherry-picking\nbugfix, or by reverting some change one one branch while other is from\nbefore a change). See for example sample history below\n\n\n .---.---.---a--.---b---.---c <--- branch_1\n \\\n \\--.---d---c' <--- branch_2\n\nwhere given file is at the same version (has the same contents) in both\n\"c\" and \"c'\" commits, but for one 'last changed' would be \"b\", for other\nit would be \"d\".\n\nThis means that not only rewinding is costly (as per previous point), but\nalso switching branches is costly; you have to get history for each and\nevery file, even if they didn't change in the switch.\n\nThird, files in project are not independent. Last commit the file was\nchanged doesn't give us much informational value, I don't think. Well,\nat least not as keyword expansion; you might want to ask your SCM about\nthis info. Whole project tags means that you can get to exact version\nyou stated. \"File history\" revision numbers would not.\n\n\nI don't know why you need such keyword. Users either browse files via SCM\n(where they have access to SCM to get such info, or browse files from\ntarball, where project revision is embedded (substituted by Makefile)...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"113897","messageId":"vpqskj8p3fu.fsf@bauges.imag.fr","threadId":"19334","inReplyTo":"200905140102.15578.jnareb@gmail.com","subject":"Re: update @version in file","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-05-14T07:08:05Z","receivedAt":"2009-05-14T07:08:05Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> I don't know why you need such keyword.\n\nHey, don't get me wrong: I didn't say I needed it, but just that it\nwasn't completely meaningless. No intention to flame, sorry ;-).\n\n-- \nMatthieu\n"}]}