{"thread":{"id":"45849","subject":"Could GIT manage revision headers embedded in code ?","startedAt":"2017-05-02T11:54:09Z","lastAt":"2017-05-02T15:54:37Z","messageCount":4,"participants":["Delanoe Eric","Christian Couder","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"318485","messageId":"135C7A92C7D64E488B830ADC2970C70132AE6407@SVGEA-EMAIL.gea.fr","threadId":"45849","inReplyTo":null,"subject":"Could GIT manage revision headers embedded in code ?","fromName":"Delanoe Eric","fromEmail":"e.delanoe@gea.fr","sentAt":"2017-05-02T11:48:35Z","receivedAt":"2017-05-02T11:54:09Z","isPatch":false,"sender":{"key":"e.delanoe@gea.fr","avatar":null},"body":"Hello,\n\nWe need a great deal of traceability for our source, made of many scripts in interpreted languages, spread in many \"independent\" modules, as far as can be ;-).\nIn particular, somebody troubleshooting a script in production should be able to know exactly the revision or commit ID (or tag label) of a given file, and its location in the GIT source directory tree.\n\nOur old CVS... let's say it was its only advantage... was doing this with keywords embedded in code comments: $Header$, $Id$, $Rev$, $File$ etc... When a file was committed, its $Header$ keyword was expanded into a rich piece of \"version\" information like '' $Header: /cvsstore/SourcesOracle/Install/COMMUN/CST.sql,v 1.69.2.10 2017/04/14 09:38:48 edelanoe $\".\n\nCould this kind of \"keyword expansion\" feature be added into GIT ?\nFocusing on the goal: enable the identification of a file and its revision(*) inside the committed code itself.\n(*) the \"revision\" information or a commit ID. The tag(s) attached at commit time would be less reliable, as a tag can be moved between revisions.\n\nThank you in advance for any answer,\nBest regards,\nE.Delanoë\n\nGrenobloise d'Electronique et d'Automatismes\nInovallée - 12, Chemin de Malacher\n38243 MEYLAN CEDEX \nFRANCE\n"},{"id":"318487","messageId":"CAP8UFD0NrTyGYgHeEOWpUH5v0ejKvcKu+Mzd8_scYbvzL4b4zg@mail.gmail.com","threadId":"45849","inReplyTo":"135C7A92C7D64E488B830ADC2970C70132AE6407@SVGEA-EMAIL.gea.fr","subject":"Re: Could GIT manage revision headers embedded in code ?","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2017-05-02T12:11:16Z","receivedAt":"2017-05-02T12:11:22Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Tue, May 2, 2017 at 1:48 PM, Delanoe Eric <e.delanoe@gea.fr> wrote:\n> Hello,\n>\n> We need a great deal of traceability for our source, made of many scripts in interpreted languages, spread in many \"independent\" modules, as far as can be ;-).\n> In particular, somebody troubleshooting a script in production should be able to know exactly the revision or commit ID (or tag label) of a given file, and its location in the GIT source directory tree.\n>\n> Our old CVS... let's say it was its only advantage... was doing this with keywords embedded in code comments: $Header$, $Id$, $Rev$, $File$ etc... When a file was committed, its $Header$ keyword was expanded into a rich piece of \"version\" information like '' $Header: /cvsstore/SourcesOracle/Install/COMMUN/CST.sql,v 1.69.2.10 2017/04/14 09:38:48 edelanoe $\".\n>\n> Could this kind of \"keyword expansion\" feature be added into GIT ?\n\nYou can already do it with \"smudge\" and \"clean\" filters. Look for\n\"Keyword Expansion\" in:\n\nhttps://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes\n"},{"id":"318498","messageId":"135C7A92C7D64E488B830ADC2970C70132AE7442@SVGEA-EMAIL.gea.fr","threadId":"45849","inReplyTo":"CAP8UFD0NrTyGYgHeEOWpUH5v0ejKvcKu+Mzd8_scYbvzL4b4zg@mail.gmail.com","subject":"RE: Could GIT manage revision headers embedded in code ?","fromName":"Delanoe Eric","fromEmail":"e.delanoe@gea.fr","sentAt":"2017-05-02T13:33:58Z","receivedAt":"2017-05-02T13:34:05Z","isPatch":false,"sender":{"key":"e.delanoe@gea.fr","avatar":null},"body":"Thank you for your quick answer.\nAnd great answer ! I'm looking forward to try this.\n\nThanks again and best regards,\nE.Delanoë\n\n\n-----Message d'origine-----\nDe : Christian Couder [mailto:christian.couder@gmail.com] \nEnvoyé : mardi 2 mai 2017 14:11\nÀ : Delanoe Eric\nCc : git@vger.kernel.org\nObjet : Re: Could GIT manage revision headers embedded in code ?\n\nHi,\n\nOn Tue, May 2, 2017 at 1:48 PM, Delanoe Eric <e.delanoe@gea.fr> wrote:\n> Hello,\n>\n> We need a great deal of traceability for our source, made of many scripts in interpreted languages, spread in many \"independent\" modules, as far as can be ;-).\n> In particular, somebody troubleshooting a script in production should be able to know exactly the revision or commit ID (or tag label) of a given file, and its location in the GIT source directory tree.\n>\n> Our old CVS... let's say it was its only advantage... was doing this with keywords embedded in code comments: $Header$, $Id$, $Rev$, $File$ etc... When a file was committed, its $Header$ keyword was expanded into a rich piece of \"version\" information like '' $Header: /cvsstore/SourcesOracle/Install/COMMUN/CST.sql,v 1.69.2.10 2017/04/14 09:38:48 edelanoe $\".\n>\n> Could this kind of \"keyword expansion\" feature be added into GIT ?\n\nYou can already do it with \"smudge\" and \"clean\" filters. Look for \"Keyword Expansion\" in:\n\nhttps://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes\n"},{"id":"318510","messageId":"alpine.DEB.2.20.1705021751250.3480@virtualbox","threadId":"45849","inReplyTo":"135C7A92C7D64E488B830ADC2970C70132AE6407@SVGEA-EMAIL.gea.fr","subject":"Re: Could GIT manage revision headers embedded in code ?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-05-02T15:54:28Z","receivedAt":"2017-05-02T15:54:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Tue, 2 May 2017, Delanoe Eric wrote:\n\n> Could this kind of \"keyword expansion\" feature be added into GIT ?\n\nBack in the days, it was decided that this should be part of the \"export\nas zip\" functionality, see the `export-subst` feature in git-archive's and\ngitattributes' documentation.\n\nIn reality, what most projects do is to generate a header or some such as\npart of their build process. Git itself may serve as a case in point:\n\n\thttps://github.com/git/git/blob/master/GIT-VERSION-GEN\n\nused in\n\n\thttps://github.com/git/git/blob/v2.12.2/Makefile#L390-L392\n\nCiao,\nJohannes\n"}]}