Equivalente de Git a $ URL $ expansión $ keyword de subversion

Question

Estoy considerando migrar de subversion a git. Una de las cosas que utilizamos es la subversión para que nuestros administradores de sistemas administren cosas como archivos de configuración. Con ese fin, ponemos $URL$ en cada archivo, que se expande a la ubicación del archivo en el árbol de subversión. Esto permite que los administradores observen un archivo en un host arbitrario y descubran en qué árbol se encuentra.

El análogo más cercano que pude encontrar es gitattributes. Existe la directiva filter=, pero parece que git no comunica al filtro qué nombre de archivo está filtrando, lo que sería necesario para convertir $URL$ en una ruta.

También está la directiva ident, que convertiría $Id$ en el hash blob. Esto podría ser útil si uno pudiera mapear eso en una ruta, pero mi git-fu no es lo suficientemente fuerte.

¿Alguna sugerencia?

El flujo de trabajo es el siguiente:

1. administración se compromete cambios en el repositorio VCS
2. administrador actualiza una ubicación central, que ha comprobado el repositorio
3. administración tira de los cambios en el host mediante cfengine

Answer 1

Como se menciona en "Does git have anything like svn propset svn:keywords or pre-/post-commit hooks?", Git no admite la expansión de palabras clave.

"Dealing with SVN keyword expansion with git-sv" proporciona una solución basada en git config filter (que no es exactamente lo que desea) y/o gitattributes.

---

El ejemplo más cercano si la expansión información del archivo que he encontrado todavía basado en la mancha/enfoque limpio, with this git Hash filter, pero la parte limpia elimina del archivo, y ningún camino puede ser encontrado.

This thread realidad lo explica (así como mencionar algunos git-fu comandos que puede contener lo que está buscando, no los he probado):

De todos modos, las manchas/limpia no da la solución inmediata al problema debido a pequeñas deficiencias técnicas:

• filtro mancha no se pasa un nombre de archivo que se está desprotegido, por lo que no es posible encontrar exactamente el identificador de comprometerse.
  Sin embargo, esto se alivia por el hecho de que 'mancha' solo se ejecuta para los archivos modificados, por lo que el último compromiso es el necesario.

• filtro de mancha no se pasa un identificador de compromiso. Esto es un poco más serio, ya que de lo contrario no se puede obtener esta información.
  Intenté usar el valor 'HEAD', pero aparentemente todavía no está actualizado en el momento en que se está ejecutando 'mancha', por lo que los archivos terminan con la fecha de la confirmación "anterior" en lugar de desproteger la confirmación.
  "Anterior" hace referencia a la confirmación que se ha desprotegido anteriormente. El problema empeora si se realiza una extracción diferente, ya que los archivos reciben la marca de tiempo de una rama anterior.

AFAIR, la falta de información en el filtro de mancha fue intencional, para desalentar este uso particular de las manchas/mecanismo limpio. Sin embargo, creo que esto se puede reconsiderar dado el caso de uso de Peter: espacio de trabajo "solo pago" para publicación inmediata en el servidor web.
Alternativamente, cualquier persona interesada en este caso de uso podría implementar argumentos de borrones adicionales como un parche de sitio local.

Y luego, hay pequeñas molestias, que parecen ser inevitables: si cambia el filtro 'clean' y echa un vistazo a la revisión anterior, se informará que tiene modificaciones (debido a la definición 'limpia' modificada).

Answer 2

Al abordar el problema desde un ángulo completamente diferente, ¿cómo terminan los archivos en cuestión en los hosts finales? ¿Supongo que hoy se puede consultar directamente allí, o copiarse de algún modo desde un repositorio ya desprotegido en otro host?

Si es así, ¿podría modificar su proceso de manera que los archivos se pueden sacar a un repositorio git, y un script hace el $URL$ u otra palabra clave expansión después pago y envío. De esta forma, puede hacer las sustituciones que desee, y solo estar limitado por lo que puede encontrar un script en un repositorio desprotegido.

Answer 3

Utilizamos una solución de "ruta canónica" en nuestras implementaciones (todas son internas, FWIW).

Todo el software entra, p. Ej. /d/sw/xyz/a.c o D: \ SW \ xyz \ A.C.

Todas las URL a los archivos desplegados reflejan que, por ejemplo, http: //host/d/sw/xyz/a.c.

Las URL de los archivos del repositorio comienzan en "sw", p. Ej. git: // githost/gitrepo/xyz/ac

Nos codificar estos caminos canónicos en la configuración (en caso de que alguna vez tiene que cambiar), y tenemos los scripts/API que generan/referencia a URLs sobre la marcha de vinculación dinámica entre componentes.

Answer 4

Dado que actualmente existe la opción %f, los scripts como git-rcs-keywords pueden hacer la tarea.

Ya se menciona en this answer.

gitattributes(5) manpage:

Sequence "%f" on the filter command line is replaced with 
the name of the file the filter is working on. A filter 
might use this in keyword substitution. For example: 

[filter "p4"] 
    clean = git-p4-filter --clean %f 
    smudge = git-p4-filter --smudge %f