svn - migrar - subgit

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

Question

Hace poco pregunté sobre la 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 hacer mi control de versión. Desafortunadamente, git-svn no es compatible con esto, de acuerdo con los documentos:

"Ignoramos todas las propiedades de SVN excepto svn: executable"

Pero no parece demasiado complicado tener este material de palabras clave emulado por un par de ganchos de confirmación previa / posterior. ¿Soy la primera persona en querer esto? ¿Alguien tiene un código para hacer esto?

Answer 1

Desafortunadamente, la sustitución de palabras clave RCS rompe esto. Por ejemplo, usar $ Date $ requeriría que git checkout tocara cada archivo en el árbol al cambiar de rama.

Eso no es verdad. $ Date $ etc. expanda al valor que se mantiene al 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.

Answer 2

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

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

No es tan fácil de configurar como a uno le gustaría, pero parece funcionar. Utiliza un par de filtro de borrado / limpieza escrito en perl (similar a lo que describió la respuesta de emk), y sí, tocará todos los archivos con las extensiones establecidas en .gitattributes, en general reduciendo un poco la velocidad de las cosas.

Answer 3

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

$Id: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef$

donde deadbeef... es el sha1 del blob correspondiente a ese archivo. Si realmente necesita la expansión de palabras clave, y la necesita en el git repo (en lugar de un archivo exportado), creo que tendrá que ir con el ident gitattribute con un script personalizado que haga la expansión por usted. El problema con solo usar un gancho es que el archivo en el árbol de trabajo no coincide con el índice, y git pensaría que ha sido modificado.

Answer 4

Qué está pasando aquí: Git está optimizado para cambiar de rama 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, usar $Date$ requeriría que git checkout tocara cada archivo en el árbol al cambiar de rama. Para un repositorio del tamaño del kernel de Linux, esto pondría todo a un frenazo chirriante.

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

$ git tag v0.5.whatever

... y luego llama al siguiente comando desde tu Makefile:

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

Aquí, git me dice que estoy trabajando en una versión anónima de 6 commits pasada v0.5.15.1, con un hash SHA1 que comienza con g61cde1d . Si coloca la salida de este comando en un archivo *.h alguna parte, está en el negocio y no tendrá problemas para vincular el software liberado al código fuente. Esta es la forma preferida de hacer las cosas.

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

Pero, si no puede evitar las palabras clave de RCS, lo siguiente debe 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 lograr que el shell escape en los comandos de smudge y smudge , simplemente escriba sus propios scripts de Perl para expandir y eliminar palabras clave de RCS, respectivamente, y use esos scripts como su filtro.

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