it-swarm-es.tech

Manejo de la expansión de palabras clave SVN con git-svn

Recientemente pregunté sobre expansión de palabras clave en Git y estoy dispuesto a aceptar el diseño para no apoyar realmente esta idea en Git.

Para bien o para mal, el proyecto en el que estoy trabajando en este momento requiere una expansión de palabras clave SVN como esta:

svn propset svn:keywords "Id" expl3.dtx

para mantener esta cadena actualizada:

$Id: expl3.dtx 803 2008-09-11 14:01:58Z will $

Pero me gustaría usar Git para controlar mi versión. Desafortunadamente, git-svn no admite esto, según los documentos:

"Ignoramos todas las propiedades SVN excepto svn: ejecutable"

Pero no parece demasiado complicado tener estas palabras clave emuladas por un par de ganchos de confirmación previa/posterior. ¿Soy la primera persona que quiere esto? ¿Alguien tiene algún código para hacer esto?

42
Will Robertson

Lo que está sucediendo aquí: Git está optimizado para cambiar entre ramas lo más rápido posible. En particular, git checkout está diseñado para no tocar ningún archivo que sea idéntico en ambas ramas.

Desafortunadamente, la sustitución de palabras clave RCS rompe esto. Por ejemplo, usando $Date$ requeriría git checkout para tocar todos los archivos del árbol al cambiar de rama. Para un repositorio del tamaño del kernel de Linux, esto detendría todo.

En general, su mejor opción es etiquetar al menos una versión:

$ git tag v0.5.whatever

... y luego llame al siguiente comando desde su Makefile:

$ git describe --tags
v0.5.15.1-6-g61cde1d

Aquí, git me dice que estoy trabajando en una versión anónima 6 confirma el v0.5.15.1 anterior, con un hash SHA1 que comienza con g61cde1d. Si pega la salida de este comando en un *.h archiva en algún lugar, estás en el negocio y no tendrás problemas para vincular el software lanzado de nuevo al código fuente. Esta es la forma preferida de hacer las cosas.

Si no puede evitar el uso de palabras clave RCS, puede comenzar con esto explicación de Lars Hjemli . Básicamente, $Id$ es bastante fácil, y tú si estás usando git archive, también puedes usar $Format$.

Pero, si no puede evitar las palabras clave RCS, lo siguiente debería ayudarlo a comenzar:

git config filter.rcs-keyword.clean 'Perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
git config filter.rcs-keyword.smudge 'Perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date: `date`\\\$/"'

echo '$Date$' > test.html
echo 'test.html filter=rcs-keyword' >> .gitattributes
git add test.html .gitattributes
git commit -m "Experimental RCS keyword support for git"

rm test.html
git checkout test.html
cat test.html

En mi sistema, obtengo:

$Date: Tue Sep 16 10:15:02 EDT 2008$

Si tiene problemas para que los escapes de Shell en los comandos smudge y clean funcionen, simplemente escriba sus propios scripts de Perl para expandir y eliminar palabras clave RCS, respectivamente, y use esos scripts como filtro.

Tenga en cuenta que usted realmente no desea hacer esto para más archivos de los absolutamente necesarios, o git perderá la mayor parte de su velocidad.

39
emk

Desafortunadamente, la sustitución de palabras clave RCS rompe esto. Por ejemplo, usar $ Date $ requeriría que git checkout toque todos los archivos del árbol al cambiar de rama.

Eso no es verdad. $ Date $ etc. se expande al valor que se mantiene en el momento del registro. Eso es mucho más útil de todos modos. Por lo tanto, no cambia en otras revisiones o ramas, a menos que el archivo se vuelva a registrar. Del manual de RCS:

   $Date$ The  date  and  time the revision was checked in.  With -zzone a
          numeric time zone offset is appended;  otherwise,  the  date  is
          UTC.

Esto también significa que la respuesta sugerida anteriormente, con el filtro rcs-keyword.smudge, es incorrecta. Inserta la hora/fecha del pago, o lo que sea que hace que se ejecute.

22
Rhialto

Aquí hay un proyecto de muestra que contiene la configuración y el código de filtro necesarios para agregar soporte de palabras clave RCS a un proyecto git:

https://github.com/turon/git-rcs-keywords

No es tan simple de configurar como uno quisiera, pero parece funcionar. Utiliza un par de filtro borroso/limpio escrito en Perl (similar a lo que se describe en la respuesta de emk), y sí, tocará todos los archivos con las extensiones establecidas en atributos .gitattributes, generalmente ralentizando un poco las cosas.

6
turon

Puede establecer el atributo ident en sus archivos, pero eso produciría cadenas como

$Id: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef$

dónde deadbeef... es el sha1 del blob correspondiente a ese archivo. Si realmente necesita esa expansión de palabras clave, y la necesita en el repositorio de git (en lugar de un archivo exportado), creo que tendrá que ir con el atributo ident gitat con un script personalizado que La expansión para ti. El problema con solo usar un gancho es que el archivo en el árbol de trabajo no coincidiría con el índice, y git pensaría que se ha modificado.

1
Lily Ballard