2008-09-02 15 views
34

Al hojear la documentación de git, no puedo ver nada análogo a los ganchos de confirmación de SVN o las características de "propset" que pueden, digamos, actualizar un número de versión o aviso de copyright dentro de un archivo cada vez que se envía al repositorio.¿Tiene git algo como `svn propset svn: keywords` o ganchos de pre/post-commit?

¿Se espera que los usuarios de git escriban scripts externos para este tipo de funcionalidad (lo cual no parece descartado) o me he olvidado de algo obvio?

Editar: Para ser claro, estoy más interesado en, por ejemplo,

svn propset svn:keywords "Author Date Id Revision" expl3.dtx 

donde una cadena como esta:

$Id: expl3.dtx 780 2008-08-30 12:32:34Z morten $ 

se mantiene hasta al día con la información relevante cada vez que se produce una confirmación.

Respuesta

14

Citando del Git FAQ:

¿Se tienen git expansión de palabras clave?

No recomendado. La expansión de palabras clave causa todo tipo de problemas extraños y no es realmente útil de todos modos, especialmente dentro del contexto de un SCM. Fuera de git, puede realizar la expansión de palabras clave con un script. El script de exportación del kernel de Linux hace esto para establecer la variable EXTRA_VERSION en el archivo Makefile.

Ver gitattributes (5) si realmente quieres hacer esto. Si su traducción no es reversible (por ejemplo, expansión de palabra clave SCCS), esto puede ser problemático.

+5

He encontrado esto que funciona bastante bien con proyectos git: https : //github.com/turon/git-rcs-keywords – Mark

+0

@PA Si la respuesta libre no le conviene, ignórela. A partir de los enlaces que figuran aquí, es bastante fácil encontrar una mejor explicación. Quejarse tampoco te ayuda a obtener conocimiento. Y se llama Git, no GIT. –

+1

Gracias por el puntero a las preguntas frecuentes de Git. Encontré esta cita divertida: "La expansión de palabras clave ... de todos modos no es realmente útil". Como desarrollador de soporte, me refiero a los atributos del código fuente diariamente. Por ejemplo, los procedimientos almacenados de nuestra base de datos están en control de fuente con los atributos de revisión en la parte superior. Puedo usar un atributo de revisión para verificar qué versión del procedimiento almacenado está instalado en una base de datos. –

2

Quizás la propiedad más común de SVN, 'svn: ignorar' se haga a través del archivo .gitignore, en lugar de los metadatos. Me temo que no tengo nada más útil para los otros tipos de metadatos.

4

Git tiene anzuelos precompromisos y postcompromisos, se encuentran dentro de cada directorio .git/hooks. Simplemente modifique los archivos y modifíquelos para que sean ejecutables.

18

Escribí un fairly complete answer en otro lugar, con un código que muestra cómo hacerlo. Un resumen:

  1. Probablemente no desee hacer esto. Usar git describe es una alternativa razonable.
  2. Si necesita hacer esto, $Id$ y $Format$ son bastante fáciles.
  3. Cualquier cosa más avanzada requerirá el uso de gitattributes y un filtro personalizado. Proporciono una implementación de ejemplo de $Date$.

Las soluciones basadas en funciones de enlace generalmente no son útiles, ya que hacen que su copia de trabajo esté sucia.

1

Aunque es un viejo Q & A. Pensé en tirar uno porque esto me ha estado molestando por mucho tiempo.

Estoy acostumbrado a enumerar los archivos en un directorio por orden de tiempo inverso (¿me parece gracioso, je?).La razón es que me gustaría ver qué archivos tengo (o alguien más) cambiado recientemente.

Git arruinará mis planes porque al cambiar una sucursal, el repositorio local sobrescribirá completamente los archivos rastreados de las copias (incrementales ... lo sé ...) que se encuentran en el repositorio local empaquetado.

De esta forma, todos los archivos que fueron desprotegidos llevarán el sello de tiempo de la salida y no reflejarán el tiempo de la última modificación ..... Qué molesto.

Por lo tanto, he ideado una sola línea en bash que actualizar un $ Fecha: propiedad $ dentro de cualquier archivo con el tiempo de la última modificación de acuerdo a lo que tiene en SISTEMA DE ARCHIVOS de tal manera que voy a tener una información sobre el estado inmediato de la última modificación sin tener que explorar el git log, git show o cualquier otra herramienta que proporcione los tiempos de confirmación en el modo culpar a.

El siguiente procedimiento modificará la palabra clave $ Date: $ solo en los archivos rastreados que se van a comprometer con el repositorio. Utiliza git diff --name-only, que enumerará los archivos que se modificaron, y nada más ....

Uso este único liner manualmente antes de confirmar el código. Sin embargo, una cosa es que tengo que navegar hasta el directorio raíz del repositorio antes de aplicar esto.

Aquí está la variante de código para Linux (pegado como una de varias líneas para facilitar la lectura)

git diff --name-only | xargs stat -c "%n %Y" 2>/dev/null | \ 
perl -pe 's/[^[:ascii:]]//g;' | while read l; do \ 
    set -- $l; f=$1; shift; d=$*; modif=`date -d "@$d"`; \ 
    perl -i.bak -pe 's/\$Date: [\w \d\/:,.)(+-]*\$/\$Date: '"$modif"'\$/i' $f; \ 
    git add $f; done 

y OSX

git diff --name-only | xargs stat -f "%N %Sm" | while read l; do \ 
    set -- $l; f=$1; shift; d=$*; modif=`date -j -f "%b %d %T %Y" "$d"`; \ 
    perl -i.bak -pe 's/\$Date: [\w \d\/:,.)(+-]*\$/\$Date: '"$modif"'\$/i' $f; \ 
    git add $f; done 
Cuestiones relacionadas