GIT comentario reemploop e inyección

¿Puede GIT hacer la inyección / reemploop de token en el punto de verificación del código?

PVCS hizo algo por la empresa XYZ mediante el reemploop de inyección / token de los valores. Caso en punto:

Si tenemos un código que se parece a esto:

/* $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 lo convertiría en lo siguiente, los aspectos destacados en amarillo serían las actualizaciones del file y los aspectos destacados en verde son mis comentarios.

 /* $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) */ 

¿Podemos hacer eso si es así, qué tenemos que cambiar para asegurarnos de poder hacerlo de manera uniforme en toda la base de código fuente?

git admite algunas funciones de expansión variable limitadas, aunque no se realizan en el momento del check-in. En git help gitattributes , vea las secciones en ident y export-subst , así como las opciones de filter mencionadas en la respuesta de VonC. La expansión de ident produce en el process de finalización de la transacción, mientras que el elemento de export-subst solo se produce cuando se utiliza el git archive . La opción de filter aplica a las routes de checkin y checkout, y puede ser mucho más general, pero una configuration útil requiere bastante trabajo para cualquier cosa que tenga requisitos diferentes para diferentes types de files (por ejemplo, código C vs scripts de shell; comentarios diferentes). formattings) u otros requisitos complejos.

Puede probar un controller de filter de contenido , específicamente un filter limpio

filtro limpio

(image que se muestra en " Personalizar Git – Atributos de Git ", de " Pro Git book ")

Puede ejecutar un script de su elección a un file específico o set de files declarados en .gitattributes .

El .gitattributes está versionado y será visible / utilizado por todos los desarrolladores.

Pero el filter de contenido debe ser activado por una directiva git config.

 git config filter.xxx.clean 'script' 

Y esa es una configuration local que necesita ser repetida por todos los desarrolladores, por lo que podría no ser la ideal.