tag - ¿qué hace git log-oneline?

¿Puedo agregar metadatos a las confirmaciones de git? O puedo ocultar algunas etiquetas en gitk (2)

Quiero asociar metadatos personalizados con una git commit . Específicamente para grabar una ID de revisión de una revisión de código, pero podría ser cualquier cosa. Las etiquetas parecen una forma natural de hacerlo, pero espero tener una revisión para cada confirmación y no quiero gitk a gitk con toneladas de etiquetas. ¿Hay algún otro mecanismo para agregar metadatos personalizados? ¿Puedo hacer que ciertas etiquetas sean invisibles? Si pudiera decirle a gitk no muestre etiquetas que coincidan con algún patrón o RE, probablemente funcione, pero no veo la manera de hacerlo.

Git-notas

Con las git notes puedes agregar una "nota" a una confirmación. También puede agregarlos a otros objetos de Git, pero centrémonos en los commits, ya que de eso se trata la pregunta.

Una nota es un objeto Git y, en principio, puede ser "lo que sea" (datos arbitrarios). Pero nos enfocaremos en algo simple y textual para nuestros propósitos.

Ejemplo: revisar id

La pregunta menciona los id de revisión, así que inventemos alguna forma de representar tal cosa. No sé qué aspecto tienen los ID de revisión, pero espero que lo siguiente sea sensato:

Review-id: 42

Entonces este es efectivamente un par clave-valor. Agreguemos la cadena anterior a la confirmación actual:

git notes add -m "Review-id: 42"

Si ejecuta el git log la nota se mostrará en línea †:

Author: Victor Version Control <[email protected]> Date: Tue Nov 8 21:10:25 2016 +0100 Implement feature x Notes: Review-id: 42

Otro ejemplo

Por supuesto, puede agregar más "notas secundarias" a esta nota (nos quedaremos con la key: value simple key: value sintaxis de key: value , un valor por línea). Por ejemplo, si descubrió tres meses más tarde que el mensaje de confirmación obtuvo algo incorrecto, solo agregue la corrección a la nota:

git notes append -m "Errata: It was actually feature y."

git log :

Author: Victor Version Control <[email protected]> Date: Tue Nov 8 21:10:25 2016 +0100 Implement feature x Notes: Review-id: 42 Errata: It was actually feature y.

Usamos git notes append para agregar fácilmente estos datos adicionales a la nota. También puede usar la git notes edit para editar el archivo directamente.

Por supuesto, como una nota de Git es solo un archivo mutable, puede encontrarse con conflictos de fusión. Para hacerlo menos probable, puedes:

Se adhieren a datos simples como el anterior (una clave-valor por línea).
Use estrategias especiales de fusión; vea man git-notes , sección "Estrategias de fusión de notas".

Visibilidad

El OP preguntó:

> ¿Puedo hacer que ciertas etiquetas sean invisibles?

De forma predeterminada, el git log solo muestra una nota, a saber, .git/refs/notes/commits . commits es solo una nota en el espacio de nombres. Tal vez quieras que los problemas estén en su propio espacio de nombres:

git notes --ref=issues add -m "Fixes: #32"

Como esto se almacena en .git/refs/notes/issues y no en .git/refs/notes/commits , "Fixes: # 32" no se mostrará cuando ejecute git log . Por lo tanto, ha hecho que esas notas sean invisibles por defecto.

Si quieres que se muestre, pasa --notes=issues al git log :

$ git log --notes=issues Author: Victor Version Control <[email protected]> Date: Tue Nov 8 21:10:25 2016 +0100 Implement feature x Notes (issues): Fixes: #32

Pero ahora .git/refs/notes/commits están ocultos. Ese también se puede incluir fácilmente:

$ git log --notes=issues --notes=commits Author: Victor Version Control <[email protected]> Date: Tue Nov 8 21:10:25 2016 +0100 Implement feature x Notes (issues): Fixes: #32 Notes: Review-id: 42 Errata: It was actually feature y.

Hay variables para configurar qué notas se muestran por defecto; ver man git-config .

Beneficios en comparación con los mensajes de compromiso

Los metadatos pueden, por supuesto, registrarse en el mensaje de compromiso directamente. Pero los mensajes de compromiso son inmutables, por lo que cambiarlos realmente significa hacer un compromiso completamente nuevo, con todas las consecuencias que esto conlleva. Los Git-Notes, por otro lado, son mutables, por lo que siempre puedes revisarlos. Y cada modificación de una nota es, por supuesto, una versión controlada. En nuestro caso, para .git/refs/notes/commits :

$ git log refs/notes/commits Author: Victor Version Control <[email protected]> commit 9f0697c6bbbc6a97ecce9834d4c9afa0d668bcad Date: Tue Nov 8 21:13:52 2016 +0100 Notes added by ''git notes append'' commit b60997e49444732ed2defc8a6ca88e9e21001a1d Author: Victor Version Control <[email protected]> Date: Tue Nov 8 21:10:38 2016 +0100 Notes added by ''git notes add''

Compartir notas

Tus notas no son compartidas por defecto; tienes que hacerlo explícitamente Y en comparación con otras referencias, compartir notas no es muy fácil de usar. Tenemos que usar la sintaxis refspec :

git push refs/notes/*

Lo anterior llevará todas tus notas a tu control remoto.

Parece que ir a buscar notas es un poco más complicado; puedes hacerlo si especificas ambos lados del refspec:

git fetch origin refs/notes/*:refs/notes/*

Entonces eso definitivamente no es conveniente. Si tiene la intención de usar Git-notes regularmente, probablemente quiera configurar su gitconfig para que siempre obtenga las notas:

[remote "origin"] … fetch = +refs/notes/*:refs/notes/*

(Fuente: https://git-scm.com/blog/2010/08/25/notes.html )

Llevar notas sobre reescrituras

Git tiene el inconveniente inconveniente de que las notas no se transfieren cuando se reescribe una confirmación. Entonces, si, por ejemplo, rebase una serie de confirmaciones, las notas no se transferirán a las nuevas confirmaciones.

La variable notes.rewrite.<command> se establece de forma predeterminada en true , por lo que se podría suponer que las notas se notes.rewrite.<command> . Pero el problema es que la variable notes.rewriteRef , que determina qué notas se transferirán, no tiene ningún error vaule. Para establecer este valor para que coincida con todas las notas, ejecute lo siguiente:

git config --global notes.rewriteRef "refs/notes/*"

Ahora todas las notas se transferirán al hacer operaciones de reescritura como git rebase .

Llevar notas a través de parches de correo electrónico

Si usa git format-patch para formatear los cambios para enviarlos como correos electrónicos, y tiene algunos metadatos almacenados como notas de Git, puede pasar la opción --notes a git format-patch para agregar las notas al correo electrónico borrador.

† "Este es el valor predeterminado para git log [...] cuando no hay una --pretty , --format , o --oneline dada en la línea de comando." - man git-log , git version 2.10.2

Para eso son precisamente las notas git .