{"thread":{"id":"10248","subject":"RCS keyword expansion","startedAt":"2007-10-11T14:47:29Z","lastAt":"2007-10-15T14:28:51Z","messageCount":27,"participants":["Peter Karlsson","Johannes Sixt","Randal L. Schwartz","Oliver Kullmann","Alex Riesen","Lars Hjemli","Johannes Schindelin","Sam Vilain","Jan Hudec","Barry Fishman","Linus Torvalds","Florian Weimer","Salikh Zakirov","Zakirov Salikh"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55473","messageId":"Pine.LNX.4.64.0710111542420.23849@ds9.cixit.se","threadId":"10248","inReplyTo":null,"subject":"RCS keyword expansion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-11T14:47:29Z","receivedAt":"2007-10-11T14:47:29Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\nI've looked and looked, but cannot figure out how to do RCS/CVS style\nkeyword expansion with Git. The FAQ on the Wiki is quite cryptic on the\nsubject, and my googling skills fail short.\n\nI mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the\nfile was last changed. Possibly even have an $Id$ that gives me\nsomething useful (name and commit hash, perhaps?). Is it possible to do\nthis? Can it be done through git-cvsserver?\n\nI currently have my personal website in CVS and am using $Date$ to\ninclude a datestamp on the pages. I am considering converting the\nrepository to Git, but only after I can get $Date$ expansion to work.\nI am considering having the website host believe it still is a cvs\nrepository by using git-cvsserver, thus my question about expanding\n$Date$ through it.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"55475","messageId":"470E3B20.3050904@viscovery.net","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710111542420.23849@ds9.cixit.se","subject":"Re: RCS keyword expansion","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-11T15:02:56Z","receivedAt":"2007-10-11T15:02:56Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Peter Karlsson schrieb:\n> I've looked and looked, but cannot figure out how to do RCS/CVS style\n> keyword expansion with Git. The FAQ on the Wiki is quite cryptic on the\n> subject, and my googling skills fail short.\n\nCryptic?\n\nQ: Does git have keyword expansion?\nA: No.\n\nTo me this is crystal clear.\n\n:-)\n\n-- Hannes\n"},{"id":"55476","messageId":"86fy0hvgbh.fsf@blue.stonehenge.com","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710111542420.23849@ds9.cixit.se","subject":"Re: RCS keyword expansion","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-10-11T15:09:22Z","receivedAt":"2007-10-11T15:09:22Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Peter\" == Peter Karlsson writes:\n\nPeter> I mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the\nPeter> file was last changed. Possibly even have an $Id$ that gives me\nPeter> something useful (name and commit hash, perhaps?). Is it possible to do\nPeter> this? Can it be done through git-cvsserver?\n\nThat's not a job for a source code manager to do. It's a job for your\nbuild/install tool. See how \"git --version\" gets created in the core distro,\nand follow that example.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"55483","messageId":"20071011155956.GC11693@cs-wsok.swansea.ac.uk","threadId":"10248","inReplyTo":"86fy0hvgbh.fsf@blue.stonehenge.com","subject":"Re: RCS keyword expansion","fromName":"Oliver Kullmann","fromEmail":"o.kullmann@swansea.ac.uk","sentAt":"2007-10-11T15:59:56Z","receivedAt":"2007-10-11T15:59:56Z","isPatch":false,"sender":{"key":"o.kullmann@swansea.ac.uk","avatar":null},"body":"On Thu, Oct 11, 2007 at 08:09:22AM -0700, Randal L. Schwartz wrote:\n> >>>>> \"Peter\" == Peter Karlsson writes:\n> \n> Peter> I mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the\n> Peter> file was last changed. Possibly even have an $Id$ that gives me\n> Peter> something useful (name and commit hash, perhaps?). Is it possible to do\n> Peter> this? Can it be done through git-cvsserver?\n> \n> That's not a job for a source code manager to do. It's a job for your\n> build/install tool. See how \"git --version\" gets created in the core distro,\n> and follow that example.\n> \n\nThis looks like a misunderstanding of what $Date$ is used for:\nIt has not much to do with a version number (such things are decisions\nby the developers), but it is an identification stamp, typically\nused to identify exactly which piece of code is involved in a\ngiven executable.\n\nOur group also needs a replacement for the keyword-expansion mechanism\n(we are using a nice little system, which allows for each executable produced\nto query it about the source-code-files involved in it, which is especially\nuseful for testing and development, where many versions of many files\nfloat around (and perhaps some shouldn't)).\n\nThe principle solution seems quite clear to me: Adapt the pre-commit hook,\nso that files are scanned for the keyword, and apply the keyword expansion\nthen before the actual commit.\n\nBetter than just the date, it would be greatest to be able to put also\nthe SHA1-ID of the commit into the file, alas this is a bit complicated,\nsince it's a pre-commit hook; However it seems necessary to have in\nthe repository really the actual file content, not \"modulo some modification\",\ndue to the distributed character of Git repositories (everybody should have\nthe same file-timestamp), and so a post-commit hook shouldn't be used.\nSo well, using the previous SHA1-ID should be a reasonable approximation.\n\nOliver\n"},{"id":"55492","messageId":"Pine.LNX.4.62.0710111953460.7441@perkele.intern.softwolves.pp.se","threadId":"10248","inReplyTo":"86fy0hvgbh.fsf@blue.stonehenge.com","subject":"Re: RCS keyword expansion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-11T17:55:05Z","receivedAt":"2007-10-11T17:55:05Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Randal L. Schwartz:\n\n> That's not a job for a source code manager to do. It's a job for your \n> build/install tool.\n\nSince there is no build step involved (my web site is just a CVS checkout at \nthe moment), it's a job for the checkout step. I'd really want to avoid \nhaving a separate copy of the web site just so that I can do a \"make \ninstall\". That would sort of negate the savings in disk space I hope seeing \nby moving from CVS to Git.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"55489","messageId":"20071011180958.GA2804@steel.home","threadId":"10248","inReplyTo":"20071011155956.GC11693@cs-wsok.swansea.ac.uk","subject":"Re: RCS keyword expansion","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-11T18:09:58Z","receivedAt":"2007-10-11T18:09:58Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Oliver Kullmann, Thu, Oct 11, 2007 17:59:56 +0200:\n> Better than just the date, it would be greatest to be able to put also\n> the SHA1-ID of the commit into the file, alas this is a bit complicated,\n\nactually, it is quite simple: just (re)generate a file which you can\ncompile and link to your executable. That is how gits version work:\n\n $ git version\n git version 1.5.3.4.229.ga321c1\n\nthis ga321c1 is the commit (no one knows what the \"g\" stands for, but\nthe rest is plain value of HEAD at the moment of compilation).\n\nPut the generated string in your image in a greppable/identable form\nand you are set: the commit identifies uniquely the whole build tree\n(assuming your build tree _can_ be identified. It not given for most\ncommercial projects I am familiar with).\n"},{"id":"55494","messageId":"8c5c35580710111216i33ef39e4x46a9050f7f92b959@mail.gmail.com","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710111542420.23849@ds9.cixit.se","subject":"Re: RCS keyword expansion","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-10-11T19:16:48Z","receivedAt":"2007-10-11T19:16:48Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 10/11/07, Peter Karlsson wrote:\n> I've looked and looked, but cannot figure out how to do RCS/CVS style\n> keyword expansion with Git.\n\nIf you look at 'man gitattributes' you'll find a description of the\n'ident' attribute which is expanded to the SHA1 of the containing file\n during checkout.\n\nThere is also a description of the 'export-subst' attribute which can\nbe used to expand keywords when generating tar/zip files with\n'git-archive'. It supports commit SHA1 and date, among others.\n\nBtw: using git-archive means that you don't need a local repository on\nthe webserver, you only need a proper git installation. Essentially,\nyou can update your webserver 'checkout' with something like this:\n\n$ git archive --remote= --prefix=somepath/ master | tar -x\n\n--\nlarsh\n"},{"id":"55495","messageId":"20071011192103.GD2804@steel.home","threadId":"10248","inReplyTo":"Pine.LNX.4.62.0710111953460.7441@perkele.intern.softwolves.pp.se","subject":"Re: RCS keyword expansion","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-11T19:21:03Z","receivedAt":"2007-10-11T19:21:03Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Peter Karlsson, Thu, Oct 11, 2007 19:55:05 +0200:\n> >That's not a job for a source code manager to do. It's a job for your \n> >build/install tool.\n> \n> Since there is no build step involved (my web site is just a CVS checkout \n> at the moment), it's a job for the checkout step. I'd really want to avoid \n> having a separate copy of the web site just so that I can do a \"make \n> install\".\n\nThat's confusing. If your web site is just a checkout, what is the\n\"make install\" for? If it is a repo, you have the version information\nanyway, and at all times.\n\nAnd if this extra step is indeed present, why can't the \"make install\"\njust save the HEAD somewhere for later reference?\n\n> That would sort of negate the savings in disk space I hope seeing \n> by moving from CVS to Git.\n\nYou'll find you have plenty of savings for anything.\n"},{"id":"55503","messageId":"Pine.LNX.4.64.0710112144380.4174@racer.site","threadId":"10248","inReplyTo":"20071011155956.GC11693@cs-wsok.swansea.ac.uk","subject":"Re: RCS keyword expansion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-11T20:47:28Z","receivedAt":"2007-10-11T20:47:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 11 Oct 2007, Oliver Kullmann wrote:\n\n> On Thu, Oct 11, 2007 at 08:09:22AM -0700, Randal L. Schwartz wrote:\n> > >>>>> \"Peter\" == Peter Karlsson writes:\n> > \n> > Peter> I mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the\n> > Peter> file was last changed. Possibly even have an $Id$ that gives me\n> > Peter> something useful (name and commit hash, perhaps?). Is it possible to do\n> > Peter> this? Can it be done through git-cvsserver?\n> > \n> > That's not a job for a source code manager to do. It's a job for your\n> > build/install tool. See how \"git --version\" gets created in the core distro,\n> > and follow that example.\n> > \n> \n> This looks like a misunderstanding of what $Date$ is used for: It has \n> not much to do with a version number (such things are decisions by the \n> developers), but it is an identification stamp, typically used to \n> identify exactly which piece of code is involved in a given executable.\n\nIt does not matter if it is a date or a version number.\n\nThe problem is this: for efficiency, git does not change files which have \nnot changes between the last version checked out (whatever that is) and \nthe current version.\n\nThis seems counterintuitive to people coming from SVN/CVS: they expect \n_every_ file to be touched when checking out.\n\nSo there is not much we will do to accomodate in git; touching files which \nhave not changed at all (even if containing a $Id$ or a $Date$) is not the \nway we want it...\n\nAs Randal already suggested: if you need something like this, you better \nhave a build procedure which replaced $Date$ _at a given time_ (make \ninstall) with the current date.\n\nCiao,\nDscho\n"},{"id":"55507","messageId":"470E93B4.3080300@vilain.net","threadId":"10248","inReplyTo":"Pine.LNX.4.62.0710111953460.7441@perkele.intern.softwolves.pp.se","subject":"Re: RCS keyword expansion","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-10-11T21:20:52Z","receivedAt":"2007-10-11T21:20:52Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Peter Karlsson wrote:\n> Randal L. Schwartz:\n> \n>> That's not a job for a source code manager to do. It's a job for your \n>> build/install tool.\n> \n> Since there is no build step involved (my web site is just a CVS checkout at \n> the moment), it's a job for the checkout step. I'd really want to avoid \n> having a separate copy of the web site just so that I can do a \"make \n> install\". That would sort of negate the savings in disk space I hope seeing \n> by moving from CVS to Git.\n\nThe problem is that asking for the \"last commit that changed a file\" is\none of those features which comes out of the wash with proper merge\nsupport. There is often no clear answer to that question.\n\nHere's an example. Say two people apply a patch on their own branches,\nwhich are subsequently merged. The file was the same on both branches;\nthe commits may have exactly the same date, but different committers.\n\nNow, consider what happens as you are switching branches. Instead of\njust being able to check the file identity in the tree, the system has\nto somehow know that the (derived) ancestry of the file is different,\nand now the content has to change. That makes something that was\nextremely fast, slow.\n\nIt's the sort of thing that's possible to arrange to work using hooks\n(with whatever arbitrary decisions you choose to make for the areas\nwhere it would be ambiguous), but no-one bothered because people\nrealised that it probably means you're trying to encapsulate the\ninformation in the wrong place.\n\nSam.\n"},{"id":"55510","messageId":"470E9723.3090103@vilain.net","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710112144380.4174@racer.site","subject":"Re: RCS keyword expansion","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-10-11T21:35:31Z","receivedAt":"2007-10-11T21:35:31Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> The problem is this: for efficiency, git does not change files which have \n> not changes between the last version checked out (whatever that is) and \n> the current version.\n> \n> This seems counterintuitive to people coming from SVN/CVS: they expect \n> _every_ file to be touched when checking out.\n\nWell, that's not entirely true. SVN for one doesn't change the keywords\non files that haven't changed. You can't have a keyword that expands to\nthe current head revision, for instance.\n\nSVN's answer to the problem of how this works with merging is largely\narbitrary; if you are merging changes in, the $Id$ becomes expanded to\nthe merge that affected that path, not the change that introduced this\nversion of the file.\n\nSam.\n"},{"id":"55525","messageId":"Pine.LNX.4.62.0710120723480.11771@perkele.intern.softwolves.pp.se","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710112144380.4174@racer.site","subject":"Re: RCS keyword expansion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-12T05:26:21Z","receivedAt":"2007-10-12T05:26:21Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Johannes Schindelin:\n\n> The problem is this: for efficiency, git does not change files which have \n> not changes between the last version checked out (whatever that is) and \n> the current version.\n>\n> This seems counterintuitive to people coming from SVN/CVS: they expect\n> _every_ file to be touched when checking out.\n\nNo? That would just be strange. Only the files that are actually changed \nshould be updated, no others. A $Date$ or $Id$ will show the last \ntime/commit that specific file was changed, not the latest global state (I \nguess the fact that most modern VCSs have global state makes this a bit more \ndifficult to achieve, in RCS/CVS/PVCS and others the change history is local \nto a file and thus it is trivial to find the large change for that \nparticular file).\n\n> As Randal already suggested: if you need something like this, you better \n> have a build procedure which replaced $Date$ _at a given time_ (make \n> install) with the current date.\n\nBut that's not what I want. Then my build procedure would need to do a \"git \nstatus\", or whatever you use to get the last commit information about a \nfile, on each file that is changed and is to be installed. It would be a lot \neasier if that was done already on checkout through some kind of hook.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"55526","messageId":"Pine.LNX.4.62.0710120726470.11771@perkele.intern.softwolves.pp.se","threadId":"10248","inReplyTo":"20071011192103.GD2804@steel.home","subject":"Re: RCS keyword expansion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-12T05:27:58Z","receivedAt":"2007-10-12T05:27:58Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Alex Riesen:\n\n> That's confusing. If your web site is just a checkout, what is the \"make \n> install\" for?\n\nExactly. That's what I wondering.\n\n> If it is a repo, you have the version information anyway, and at all \n> times.\n\nYes, but not embedded in the page in a format that is visible to the \nvisitor. For CVS I use something like this:\n\n

$Date$

\n\nto embed the last update time into the page.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"55538","messageId":"Pine.LNX.4.64.0710121057540.25221@racer.site","threadId":"10248","inReplyTo":"Pine.LNX.4.62.0710120723480.11771@perkele.intern.softwolves.pp.se","subject":"Re: RCS keyword expansion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-12T10:02:06Z","receivedAt":"2007-10-12T10:02:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peter,\n\nplease do not play games with the To: header. We have a policy here \n(which is supposed to be good netiquette) that we keep people in the Cc: \nlist that we respond to.\n\nOn Fri, 12 Oct 2007, Peter Karlsson wrote:\n\n> Johannes Schindelin:\n> \n> > The problem is this: for efficiency, git does not change files which \n> > have not changes between the last version checked out (whatever that \n> > is) and the current version.\n> > \n> > This seems counterintuitive to people coming from SVN/CVS: they expect \n> > _every_ file to be touched when checking out.\n> \n> No? That would just be strange. Only the files that are actually changed \n> should be updated, no others. A $Date$ or $Id$ will show the last \n> time/commit that specific file was changed, not the latest global state \n> (I guess the fact that most modern VCSs have global state makes this a \n> bit more difficult to achieve, in RCS/CVS/PVCS and others the change \n> history is local to a file and thus it is trivial to find the large \n> change for that particular file).\n\nBut don't you see? When switching branches, this totally breaks down. \nNo, really, IMHO it is enough to show either the commit name or the blob \nname of the file. After all, you are not interested in the date that this \nfile was last committed, but in the _contents_.\n\nSo why not go for the contents? With CVS/SVN you only have the chance to \ndo that by date or version number. With git, we have a more powerful way: \nwe do it by a hash of the contents.\n\n> > As Randal already suggested: if you need something like this, you \n> > better have a build procedure which replaced $Date$ _at a given time_ \n> > (make install) with the current date.\n> \n> But that's not what I want. Then my build procedure would need to do a \n> \"git status\", or whatever you use to get the last commit information \n> about a file, on each file that is changed and is to be installed. It \n> would be a lot easier if that was done already on checkout through some \n> kind of hook.\n\nIf it's not what you want, I suggest rethinking what you want ;-)\n\nOtherwise it is scripting time for you. It's easy enough with git.\n\nCiao,\nDscho\n"},{"id":"55540","messageId":"Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710121057540.25221@racer.site","subject":"Re: RCS keyword expansion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-12T10:50:51Z","receivedAt":"2007-10-12T10:50:51Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\n> please do not play games with the To: header. We have a policy here \n> (which is supposed to be good netiquette) that we keep people in the Cc: \n> list that we respond to.\n\nSorry, didn't mean to do anything. I try to avoid Cc'ing people that\nare on the mailing list, and apparently strange things happened that\nkept the mailing list only as Cc. I'll try to remember setting To:\nproperly.\n\n\nBack on-topic:\n\n> But don't you see? When switching branches, this totally breaks down.\n\nWhy would it? If the file is the same on both branches, nothing would\nhappen (it is still the same version), and if the file is different, it\ngets changed anyway, and a new keyword expansion would take place.\n\n> No, really, IMHO it is enough to show either the commit name or the\n> blob name of the file. After all, you are not interested in the date\n> that this file was last committed, but in the _contents_.\n\nYes, but I want it on the lowest addressable unit size, i.e on the file\nlevel (I could possibly want to have the last commit for a set of files\nwhen I have something that get generated from several sources, but that\nis rare for a regular website, unless since javascripts and stylesheets\netc. are delivered separately).\n\nAlready today when you do \"git log\" on a file, you get the log filtered\nfor only changes to that file. So the mechanisms seem already to be\nthere, I just need to figure out how to apply them to what I want.\n\n> So why not go for the contents? With CVS/SVN you only have the\n> chance to do that by date or version number. With git, we have a more\n> powerful way: we do it by a hash of the contents.\n\nYes, but the hash if of \"everything\". I'm not interested in\n\"everything\" in this context, and I don't want to have a separate git\nrepository for each file...\n\n> If it's not what you want, I suggest rethinking what you want ;-)\n> Otherwise it is scripting time for you. It's easy enough with git.\n\nThat's what I'm trying to figure out. I assume it would be possible to\ndo with some kind of hook that is run on checkout. But I can't figure\nout how to do that.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"55541","messageId":"470F54EA.4000305@viscovery.net","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se","subject":"Re: RCS keyword expansion","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-12T11:05:14Z","receivedAt":"2007-10-12T11:05:14Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Peter Karlsson schrieb:\n>> If it's not what you want, I suggest rethinking what you want ;-)\n>> Otherwise it is scripting time for you. It's easy enough with git.\n> \n> That's what I'm trying to figure out. I assume it would be possible to\n> do with some kind of hook that is run on checkout. But I can't figure\n> out how to do that.\n\nRead about the 'filter' attribute (clean and smudge filters), e.g. here:\nhttp://www.kernel.org/pub/software/scm/git/docs/gitattributes.html\n\nThis is the place to tie a script to checkouts. How the scripts derive the \ninformation that they put in the checked-out files, is a different matter.\n\n-- Hannes\n"},{"id":"55544","messageId":"8c5c35580710120421x130c5d7dt6c9d9b5a55313180@mail.gmail.com","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se","subject":"Re: RCS keyword expansion","fromName":"Lars Hjemli","fromEmail":"lh@elementstorage.no","sentAt":"2007-10-12T11:21:58Z","receivedAt":"2007-10-12T11:21:58Z","isPatch":false,"sender":{"key":"lh@elementstorage.no","avatar":null},"body":"On 10/12/07, Peter Karlsson wrote:\n> Johannes said:\n> > So why not go for the contents? With CVS/SVN you only have the\n> > chance to do that by date or version number. With git, we have a more\n> > powerful way: we do it by a hash of the contents.\n>\n> Yes, but the hash if of \"everything\". I'm not interested in\n> \"everything\" in this context, and I don't want to have a separate git\n> repository for each file...\n\nTry this:\n\n$ echo 'File revision $Id$' > index.html\n$ echo \"*.html ident\" > .gitattributes\n$ git add index.html .gitattributes\n$ git commit\n\n>From now on, the '$Id' in index.html gets expanded to the SHA1 of the\ncontent of index.html (not the commit SHA1) each time you checkout\n(and removed when you commit)\n\nIf you still want 'last modified date', the closest thing in git is\n'commit date' which you can also get for free:\n\n$ echo 'Last commit: $Format:%cd$' > index.html\n$ echo \"*.html export-subst\" > .gitattributes\n$ git add index.html .gitattributes\n$ git commit\n$ git archive --prefix=test/ HEAD | tar -x\n$ cat test/index.html\n\nFor all supported keywords, take a look at the 'git-log --pretty=format' option\n\n--\nlarsh\n"},{"id":"55546","messageId":"Pine.LNX.4.64.0710121231410.25221@racer.site","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se","subject":"Re: RCS keyword expansion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-12T11:34:44Z","receivedAt":"2007-10-12T11:34:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 12 Oct 2007, Peter Karlsson wrote:\n\n> > But don't you see? When switching branches, this totally breaks down.\n> \n> Why would it? If the file is the same on both branches, nothing would \n> happen (it is still the same version), and if the file is different, it \n> gets changed anyway, and a new keyword expansion would take place.\n\nFinding out which commit last changed that file is slow. That's why it \nbreaks down. It is possible, yes. But then I think that you really do \nnot want this. You are just to used to CVS/SVN to see that there is a \nmuch better way in git.\n\n> > No, really, IMHO it is enough to show either the commit name or the \n> > blob name of the file. After all, you are not interested in the date \n> > that this file was last committed, but in the _contents_.\n> \n> Yes, but I want it on the lowest addressable unit size, i.e on the file \n> level (I could possibly want to have the last commit for a set of files \n> when I have something that get generated from several sources, but that \n> is rare for a regular website, unless since javascripts and stylesheets \n> etc. are delivered separately).\n\nThe lowest addressable unit size is the file level, alright. And $Id$ \ncontains the blob name. IOW it contains a key to retrieve the contents of \nexactly this version of the file.\n\nCiao,\nDscho\n"},{"id":"55556","messageId":"20071012125751.GB7865@efreet.light.src","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se","subject":"Re: RCS keyword expansion","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-10-12T12:57:51Z","receivedAt":"2007-10-12T12:57:51Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Oct 12, 2007 at 11:50:51 +0100, Peter Karlsson wrote:\n> > But don't you see? When switching branches, this totally breaks down.\n> \n> Why would it? If the file is the same on both branches, nothing would\n> happen (it is still the same version), and if the file is different, it\n> gets changed anyway, and a new keyword expansion would take place.\n\nIt does not -- the blob ID is the same. And you can indeed get $Id$ expanded\nto that (see gitattributes(5)). However, that's the ONLY thing that is the\nsame. The date of last modification or ID of commit that last touched that\nfile might not.\n\nWhy? Because git tracks content, not history. The trees and blobs (files) are\nidentified by SHA1 hashes of their content. Only commit objects add the\nnotion of history. Thus if two commits contain file with the same text, it's\nthe same file. Even if the file is the same in those commit purely by\naccident.\n\n> > No, really, IMHO it is enough to show either the commit name or the\n> > blob name of the file. After all, you are not interested in the date\n> > that this file was last committed, but in the _contents_.\n> \n> Yes, but I want it on the lowest addressable unit size, i.e on the file\n> level (I could possibly want to have the last commit for a set of files\n> when I have something that get generated from several sources, but that\n> is rare for a regular website, unless since javascripts and stylesheets\n> etc. are delivered separately).\n> \n> Already today when you do \"git log\" on a file, you get the log filtered\n> for only changes to that file. So the mechanisms seem already to be\n> there, I just need to figure out how to apply them to what I want.\n\nYes. But you need the (current) commit for that. Now if a file foo is the\nsame on branches A and B, switching between them will not touch that file,\nbut git log foo may well give you completely different results. That's why\nthere's no date or commit that last touched a file.\n\n> > So why not go for the contents? With CVS/SVN you only have the\n> > chance to do that by date or version number. With git, we have a more\n> > powerful way: we do it by a hash of the contents.\n> \n> Yes, but the hash if of \"everything\". I'm not interested in\n> \"everything\" in this context, and I don't want to have a separate git\n> repository for each file...\n> \n> > If it's not what you want, I suggest rethinking what you want ;-)\n> > Otherwise it is scripting time for you. It's easy enough with git.\n> \n> That's what I'm trying to figure out. I assume it would be possible to\n> do with some kind of hook that is run on checkout. But I can't figure\n> out how to do that.\n\nIf you read the (already mentioned) gitattributes(5) manpage, you'll find\ndescription of smudge and clean filters. They will be applied to each file\nwritten out to the tree and read back respectively. But be sure to understand\nwhy you can't -- for principial, not techical reasons -- have the date or\ncommit ID expanded correctly in all cases.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"55566","messageId":"m3y7e8jmbm.fsf@barry_fishman.acm.org","threadId":"10248","inReplyTo":"Pine.LNX.4.62.0710120726470.11771@perkele.intern.softwolves.pp.se","subject":"Re: RCS keyword expansion","fromName":"Barry Fishman","fromEmail":"barry_fishman@acm.org","sentAt":"2007-10-12T17:05:01Z","receivedAt":"2007-10-12T17:05:01Z","isPatch":false,"sender":{"key":"barry_fishman@acm.org","avatar":"https://gravatar.com/avatar/4844db8f23c87ef393afd071604bce66ae3f30c5ddd3e9002eced18b7884fa46?d=mp&s=160"},"body":"Peter Karlsson writes:\n> Yes, but not embedded in the page in a format that is visible to the\n> visitor. For CVS I use something like this:\n>\n>

$Date$

\n>\n> to embed the last update time into the page.\n>\n\nI guess everyone moving from CVS/SVN to Git faces rethinking of\nwhat the RCS markers really mean in the context of their project.\n\nIn my case the identifier was just a away of seeing when the file was\nlast changed, and who did it. I decided this fit better as an editor\nfunction, rather than a checkin function.\n\nI changed my editor (Emacs) to convert RCS Ids to timestamps when I\nopened a file for reading. This would fix old files. When i wrote out\nfiles I would update the timestamp before writing them (via emacs's\ntimestamp package). I didn't have to think about it as my RCS Id\nstamped files slowly evolve into my editor stamped ones. I'm sure I\ncould do something similar in VIM, or with a script encapsulating\nanother editor.\n\nThis actually worked out better for me. Now the timestamps were updated\neven when I hadn't yet checked in the file. Since I test things before\nchecking them in, I did not have my file changed after testing by the\ncheckin process.\n\nI could find the the commit assocated with the file fairly quickly using\n\"git log\" and finding the commit for the file just after its timestamp.\n\n-- \nBarry Fishman\n"},{"id":"55569","messageId":"alpine.LFD.0.999.0710121041220.6887@woody.linux-foundation.org","threadId":"10248","inReplyTo":"m3y7e8jmbm.fsf@barry_fishman.acm.org","subject":"Re: RCS keyword expansion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-12T17:44:37Z","receivedAt":"2007-10-12T17:44:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 12 Oct 2007, Barry Fishman wrote:\n> \n> I changed my editor (Emacs) to convert RCS Ids to timestamps when I\n> opened a file for reading. This would fix old files. When i wrote out\n> files I would update the timestamp before writing them (via emacs's\n> timestamp package). I didn't have to think about it as my RCS Id\n> stamped files slowly evolve into my editor stamped ones. I'm sure I\n> could do something similar in VIM, or with a script encapsulating\n> another editor.\n\nI think it might also be potentially interesting to make this just be a \npre-commit hook - although your point that doing it in the editor is to \nsome degree even nicer, because it also means that it shows up in diffs \neven *before* you commit.\n\nBut if you want to explore the pre-commit hook approach, what it would \nbasically boild down to is that at that point you have a list of all files \nthat have changed, and then you could run some script on them to change \nthem even further.\n\nI'm sure you'd find some problems with the approach, and I think it \nabsolutely sucks for merging (ie trivially you'll have all the merge \nproblems people *always* have with RCS Id's, and now you need to teach the \nauto-merger to hide them from you), but it's probably better than trying \nto do it at some \"core level\" (which screws up things like switching \nbranches etc).\n\n\t\t\tLinus\n"},{"id":"55570","messageId":"87ejg0fcgw.fsf@mid.deneb.enyo.de","threadId":"10248","inReplyTo":"m3y7e8jmbm.fsf@barry_fishman.acm.org","subject":"Re: RCS keyword expansion","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2007-10-12T17:51:27Z","receivedAt":"2007-10-12T17:51:27Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Barry Fishman:\n\n> I changed my editor (Emacs) to convert RCS Ids to timestamps when I\n> opened a file for reading. This would fix old files. When i wrote out\n> files I would update the timestamp before writing them (via emacs's\n> timestamp package). I didn't have to think about it as my RCS Id\n> stamped files slowly evolve into my editor stamped ones. I'm sure I\n> could do something similar in VIM, or with a script encapsulating\n> another editor.\n\nThe downside is that this causes totally unncessary conflicts when\nmerging. Maybe a custom merge handler could deal with that, though.\n"},{"id":"55571","messageId":"470FC64B.8010707@gmail.com","threadId":"10248","inReplyTo":"Pine.LNX.4.62.0710120723480.11771@perkele.intern.softwolves.pp.se","subject":"Re: RCS keyword expansion","fromName":"Salikh Zakirov","fromEmail":"salikh@gmail.com","sentAt":"2007-10-12T19:08:59Z","receivedAt":"2007-10-12T19:08:59Z","isPatch":false,"sender":{"key":"salikh@gmail.com","avatar":"https://gravatar.com/avatar/952c102bb1dcf721dab8de4f5a11d276756a65d301d021f755e265cc3251efae?d=mp&s=160"},"body":"Peter Karlsson wrote:\n> But that's not what I want. Then my build procedure would need to do a\n> \"git status\", or whatever you use to get the last commit information\n> about a file, on each file that is changed and is to be installed. It\n> would be a lot easier if that was done already on checkout through some\n> kind of hook.\n\nFor what it's worth, I've made a small exercise on git scripting \n(which I'm total newbie in), and tried to use filter mechanism\n(smudge/clean) for solving the problem Peter stated.\n\nFundamental problems of this approach were discussed in full\non the mailing list, however, as I understand Peter's situation,\nthey do not apply, as the web site workspace is 'checkout-only',\nand no actual work (commits) are made there. \nThus, it will not cause any merge problems etc.\n\nAnyway, smudge/clean does not give the immediate solution to the problem\nbecause of smaller technical shortcomings:\n* smudge filter is not passed a name of file being checked out, \n so it is not possible to exactly find the commit identifier.\n However, this is alleviated by the fact that 'smudge' is only being run\n for the changed files, so the last commit *is* the needed one.\n\n* smudge filter is not passed a commit identifier. This is a bit more serious,\n as this information is nowhere to get from otherwise. I tried to use 'HEAD'\n value, but apparently it is not yet updated at the moment 'smudge' is being\n run, so the files end up with the date of the \"previous\" commit rather than\n the commit being checked out. \"Previous\" means the commit that was checked\n out before. The problem gets worse if different branch is checkout out,\n as the files get the timestamp of a previous branch.\n\nAFAIR, lack of information in smudge filter was intentional, to discourage\nthis particular use of smudge/clean mechanism. However, I think this can be\nreconsidered given the Peter's use case: \"checkout-only\" workspace for immediate\npublishing to webserver. Alternatively, anyone interested in this use case\ncould implement additional smudge arguments as a site-local patch.\n\nAnd then, there are small annoyances, which seems to be inevitable:\n* if you change 'clean' filter and check out earlier revision, it will be\n reported as having modifications (due to changed 'clean' definition).\n\nBelow is what I ended up with:\n\n.gitattributes:\n* filter=date\n\n.git/config:\n[filter \"date\"]\n smudge = .git/smudge\n clean = .git/clean\n\n.git/clean:\n#!/usr/bin/perl -p\ns#\\$Date[^\\$]*\\$#\\$Date\\$#;\n\n.git/smudge:\n#!/usr/bin/perl\n\nuse POSIX qw(strftime);\n$branch = `git-symbolic-ref HEAD`; chomp($branch);\n$rev = `git-rev-list -n 1 $branch`; chomp($rev);\nopen REV, \"git show --pretty=raw $rev|\";\n$time = time; # default to current time\nwhile () {\n if (/^committer.* (\\d+) [\\-+]\\d*$/) {\n $time = $1;\n }\n}\nclose REV;\n\n$date = strftime \"%Y-%m-%d %H:%M:%S\", localtime($time);\nwhile (<>) {\n s#\\$Date[^\\$]*\\$#\\$Date: $date\\$#;\n print;\n}\n"},{"id":"55577","messageId":"Pine.LNX.4.64.0710122341160.25221@racer.site","threadId":"10248","inReplyTo":"470FC64B.8010707@gmail.com","subject":"Re: RCS keyword expansion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-12T22:42:40Z","receivedAt":"2007-10-12T22:42:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 13 Oct 2007, Salikh Zakirov wrote:\n\n> * smudge filter is not passed a name of file being checked out, \n> so it is not possible to exactly find the commit identifier.\n> However, this is alleviated by the fact that 'smudge' is only being run\n> for the changed files, so the last commit *is* the needed one.\n\nNo.\n\nWhen changing branches, this is not the commit you think it is.\n\nBut maybe you humour me and tell me in which context such a smudge filter \nis of use. I have yet to encounter an argument that convinces me.\n\nCiao,\nDscho\n"},{"id":"55579","messageId":"eb5812d90710121652g24b1177ao685c1ce4e0626c2d@mail.gmail.com","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710122341160.25221@racer.site","subject":"Re: RCS keyword expansion","fromName":"Zakirov Salikh","fromEmail":"salikh@gmail.com","sentAt":"2007-10-12T23:52:24Z","receivedAt":"2007-10-12T23:52:24Z","isPatch":false,"sender":{"key":"salikh@gmail.com","avatar":"https://gravatar.com/avatar/952c102bb1dcf721dab8de4f5a11d276756a65d301d021f755e265cc3251efae?d=mp&s=160"},"body":"On 13/10/2007, Johannes Schindelin wrote:\n> > * smudge filter is not passed a name of file being checked out,\n> > so it is not possible to exactly find the commit identifier.\n> > However, this is alleviated by the fact that 'smudge' is only being run\n> > for the changed files, so the last commit *is* the needed one.\n>\n> No.\n> When changing branches, this is not the commit you think it is.\n\nExactly. When switching branches, or merging or fast-forwarding several commits,\nthe last commit may not be correct. The last commit is only correct\nfor the files\nbeing updated by the fast-forward to exactly one commit.\nWhich seem to be pretty natural for the use case of checkout-only\nweb-published workspace.\n\n> But maybe you humour me and tell me in which context such a smudge filter\n> is of use. I have yet to encounter an argument that convinces me.\n\nYour comment prompted me to think about a narrower case of\nfast-forwaring to one revision.\nIn that case, 'smudge' script can have commit identifier in\nFETCH_HEAD, so the example\nscript from previous message with a little modification:\n\n $rev = `git-rev-parse FETCH_HEAD`\n\ngives *exact* solution to the originally stated problem, though for\nthe specific case\nwhen the web server directory is a checkout-only working directory,\nwhich pulls changes\nautomatically from master server (as opposed to, e.g., pushing changes\nto web server).\nEven if the server pulls several revisions at once, it is likely that\nthey are done in a close succession (otherwise automated update would\nhave picked them separately), and\nimportant part in web page timestamp is usually date.\n\nToo bad I do not really have a web server and do not need to maintain\ntimestamps in web pages ... :) git scriptability always amazed me.\n"},{"id":"55868","messageId":"Pine.LNX.4.64.0710151457131.1901@ds9.cixit.se","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710121231410.25221@racer.site","subject":"Re: RCS keyword expansion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-15T14:03:20Z","receivedAt":"2007-10-15T14:03:20Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\n> Finding out which commit last changed that file is slow. That's why\n> it breaks down.\n\nThat might be, but it only needs to be done when a file is updated.\n\n> You are just to used to CVS/SVN to see that there is a much better\n> way in git.\n\nI can see that favouring the argument that having a $Id$ that gives me\nthe global state id when the file was last updated is a bad idea. Fair\nenough. Give me a local state tham (which you did, hash id for the file\ncontents).\n\nMy problem now is the file date. That could possibly be fixed by having\nit updated before I check in the file.\n\n\nSo, to summarize, if I've understood the responses here correctly, what\nI really want is:\n\n on commit:\n - replace \"$Date$\" (or whatever) with the current time.\n - store the contents.\n\n on checkout:\n - update the file.\n - replace \"$Id$\" (ditto) with a magic identifier for the file state.\n - update git's state so that it doesn't see the \"$Id$\" expansion\n as a change in the file contents.\n\nNow the question is: Where can I find documentation on how to do this\n(i.e what should I search for--\"hooks\"?)?\n\nAnd, if this goes into the \".git\" directory, can I still have it\nreplicated when I clone a repository? I noticed that my \".git/ignore\"\nfile wasn't replicated and that I had to replace it with a local\n\".gitignore\" to get it under version control.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"55871","messageId":"Pine.LNX.4.64.0710151520040.25221@racer.site","threadId":"10248","inReplyTo":"Pine.LNX.4.64.0710151457131.1901@ds9.cixit.se","subject":"Re: RCS keyword expansion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T14:28:51Z","receivedAt":"2007-10-15T14:28:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Peter Karlsson wrote:\n\n> I wrote:\n>\n> > Finding out which commit last changed that file is slow. That's why \n> > it breaks down.\n> \n> That might be, but it only needs to be done when a file is updated.\n\nAlmost.\n\nIt also needs to be updated when switching branches. For every file. \nSince the commit blamed for the current version could be different for \nevery file.\n\n> > You are just to used to CVS/SVN to see that there is a much better way \n> > in git.\n> \n> I can see that favouring the argument that having a $Id$ that gives me \n> the global state id when the file was last updated is a bad idea. Fair \n> enough. Give me a local state tham (which you did, hash id for the file \n> contents).\n> \n> My problem now is the file date. That could possibly be fixed by having \n> it updated before I check in the file.\n> \n> \n> So, to summarize, if I've understood the responses here correctly, what\n> I really want is:\n> \n> on commit:\n> - replace \"$Date$\" (or whatever) with the current time.\n\nI think that would be more \"on edit\".\n\n> - store the contents.\n> \n> on checkout:\n> - update the file.\n> - replace \"$Id$\" (ditto) with a magic identifier for the file state.\n> - update git's state so that it doesn't see the \"$Id$\" expansion\n> as a change in the file contents.\n> \n> Now the question is: Where can I find documentation on how to do this\n> (i.e what should I search for--\"hooks\"?)?\n\nFor the $Id$ thing: Documentation/gitattributes.txt. For the $Date$ \nthing: Documentation/hooks.txt, and Documentation/git-rev-list.txt. \nYou'll need to roll your own thing there, since Git oldtimers feel that \nwhat you want to do is the wrong thing (see Randal's comment on generating \nit as part of the build process).\n\nWhat you want to do might be frowned upon by many on the list, but it is \ncertainly doable. See ExampleScripts on the wiki for inspiration.\n\n> And, if this goes into the \".git\" directory, can I still have it \n> replicated when I clone a repository? I noticed that my \".git/ignore\" \n> file wasn't replicated and that I had to replace it with a local \n> \".gitignore\" to get it under version control.\n\nNo, there is not way to have it replicated into the .git directory. The \ncommon way would be to either have it installed as templates, so that \nevery user of yours gets them automatically, or to check them in under \ndifferent names, and make every user install them by hand.\n\nThe rationale: every cloner is free to choose what hooks she wants to run. \nSo checking in such hooks is always understood as suggestion what hooks \nto install.\n\nCiao,\nDscho\n"}]}