Cómo usar $ Id y $ Format (?) En git para el text ignorado de diff en distribuciones de código fuente

Tengo un problema donde proporcionamos la fuente a un cliente que tiene que tener la información del encabezado de comentario legal específico del cliente instalado en los files fuente con varias versiones diferentes de los encabezados dependiendo de qué files fuente son (es decir, categorías especificadas por el desarrollador)

Entonces, lo que quiero es una capacidad para especificar una cadena como $Id$ o $SpecialName$ para definir qué encabezado se va a insert, que será expandido por la distribución de distribución del código (hace que los files zip o jar) en

 $SpecialName: lots of customer specific stuff like a big header of copyright, legal, and other info blah blah blah $ 

Y luego, si modifican o parchan algo en el file y lo envían nuevamente, quiero verificar los cambios en git y hacer que ignore todo entre la compilation expandida "$SpecialName:" y el siguiente "$" de la forma en que $Id$ puede ser hecho para trabajar cuando se verifican las cosas

Vi una reference a un "$Format:" en esta pregunta, pero no he encontrado references sobre qué es y si es lo que estoy buscando o no.

Idealmente, podría especificar las cadenas en el server de repository de reference "de solo lectura" y hacer que se propaguen a todos los usuarios cuando extraen cambios, pero eso es un problema aparte de lograr la funcionalidad que viene primero.


Parece que un enfoque es usar "filters" – del libro de git:

Sin embargo, ese resultado es de uso limitado. Si usó la sustitución de palabras key en CVS o Subversion, puede include una date: el SHA no es tan útil, porque es bastante aleatorio y no puede decir si un SHA es más antiguo o más nuevo que otro.

Resulta que puedes escribir tus propios filters para hacer sustituciones en los files en commit / checkout. Estos son los filters "limpio" y "difuminado". En el file .gitattributes, puede establecer un filter para routes particulares y luego configurar secuencias de commands que procesarán los files justo antes de que se cometan ("limpiar", consulte la Figura 7.2) y justo antes de que se retiren ("borrón") , vea la Figura 7.3). Estos filters se pueden configurar para hacer todo tipo de cosas divertidas.

Lo relevante aquí es que sería apropiado hacer esto en el server del repository y no en el cliente: ¿es posible el procesamiento de la precomprobación y precomprobación de los datos del "file" en el server del repository?

La forma tradicional de hacerlo es que el sistema de control de versiones realice esta expansión. Pero esto en realidad no es necesario para usted, ya que solo necesita que aparezca en las máquinas del cliente.

Solo necesita usar algún tipo de herramienta de templates en el process de compilation de la distribución del código fuente. No debería ser necesario en la mayoría de los casos hacer que ignore los encabezados si se envía un parche, porque el parche debería aplicarse de todos modos, solo con un poco de fuzz, lo que no evitará que se aplique automáticamente.