GIT comment replacement and injection

Question

Can GIT do injection/token replacement at the point of code checkin?

PVCS did something for firm XYZ by injecting/token replacement for values. Case in point:

If we have code that looked like this:

/* $Workfile:$
* Created By: [Developer Name HERE]
* Created On: [Date created in mm/dd/ccyy format, HERE]
*
* Last Revision:
* $Revision:$
* $Date:$
* $Author:$
*
* All rights reserved.
*

*/  

            [INSERT MY AMAZING CODE HERE]

/*
$Log:$
*/

PVCS would turn it into the following, Yellow highlights would be updates to the file and Green highlights are my comments.

/* $Workfile:  Constants.java  $   (Filename injected)
* Created By: [Developer Name HERE]
* Created On: [Date created in mm/dd/ccyy format, HERE]
*
* Last Revision:
* $Revision:   1.0  $
* $Date:   Jun 26 2015 06:50:52  $
* $Author:   Jsmith  $
*
* All rights reserved.
*
*/    

/*
$Log:   M:/PVCS/xxx Project Database/archives/xx/EJB/src/com/xxxxcommon/Constants.java-arc  $
//    Rev 1.0   Aug 14 2009 18:10:30   jsmith
// Initial revision.   (Comment I used at point of code check-in)
*/

Can we do that if so what do we need to change to make sure we can do it consistently across all of the source code base?

Answer 1

git does support some limited variable expansion functions, although they are not done at check-in time. In git help gitattributes, see the sections on ident and export-subst, as well as the filter options mentioned in VonC's answer. The ident expansion occurs on checkout, while the export-subst only occurs when using git archive. The filter option applies to both checkin and checkout paths, and can be much more general, but useful configuration of it takes a fair amount of work for anything that has different requirements for different sorts of files (e.g. C code vs shell scripts - different comment formats) or other complex requirements.

Answer 2

You can try out a content filter driver, specifically a clean filter

^{(image shown in "Customizing Git - Git Attributes", from "Pro Git book")}

It can execute a script of your choice to a specific file or set of files declared in a .gitattributes.

The .gitattributes is versioned and will be visible/used by all developers.

But the content filter must be activated by a git config directive.

git config filter.xxx.clean 'script'

And that is a local setting which needs to be repeated by all developers, so that might not be ideal.