¿Hay problemas para poner un "/" en un nombre de etiqueta git para crear etiquetas jerárquicas/anidadas?

Question

Creamos una etiqueta "2012/02/16" en nuestro repositorio de git. Luego notamos que dentro de Source Tree, el 2012 y el 01 estaban representados como carpetas que podían abrirse y cerrarse para revelar y ocultar las etiquetas. Tener una jerarquía anidada de etiquetas parece una buena manera de organizar las etiquetas en lugar de tener una sola lista plana.

¿Hay algún problema al hacer esto?

Cuando hago un git ls-remoto veo las siguientes entradas:

8430572c89362b875109628c33a18e782aa38488 refs/tags/2012/02/16 
d247e38159c8c4998bf8b555edfd7ffe7b945255 refs/tags/2012/02/16^{} 

no estoy seguro de lo que los^{} caracteres al final de la segunda etiqueta significan y quiero para asegurarse que este comportamiento con el que tropezamos no es algo que no deberíamos hacer antes de ir y aprovecharlo para limpiar nuestras etiquetas.

No vemos los caracteres^{} en nuestras etiquetas "no anidadas".

Answer 1

No hay problema, usar una barra es una práctica estándar, por ejemplo, en la disciplina "git-flow". Puede revisar las reglas sintácticas para los nombres de etiqueta en la página del manual git-check-ref-formato (1): http://schacon.github.com/git/git-check-ref-format.html

El símbolo de intercalación con soportes está algo GIT está tratando de decirle sobre esa etiqueta, no es algo que ha escrito . Se puede interpretar que el uso de los gitrevisions página manual (7): http://schacon.github.com/git/gitrevisions.html

Answer 2

El único problema que vas a encontrar es un mensaje de error inútil si se intenta crear una etiqueta que choca con un "directorio" de la jerarquía (causada directamente por los directorios que Git utiliza para almacenar las etiquetas que colisionan):

% git tag foo/bar 
% git tag foo 
error: there are still refs under 'refs/tags/foo' 
fatal: refs/tags/foo: cannot lock the ref 

Esto es poco probable que sea un problema en la práctica, que normalmente aparece cuando la gente intenta hacer:

v0.0.1/rc1 
v0.0.1/rc2 
v0.0.1/beta1 
v0.0.1/beta2 

entonces, intenta y etiqueta v0.0.1, que golpeará el problema anterior.

Answer 3

Además del problema de colisión de archivos/directorios, también hay un problema de sensibilidad a mayúsculas y minúsculas que puede encontrar. Si está ejecutando un sistema de archivos que no distingue entre mayúsculas y minúsculas, como Windows y Mac OS X, entonces es posible tener etiquetas en un repositorio remoto que no puede obtener/extraer. Por ejemplo, la siguiente entraría en conflicto:

archive/some-tag-or-other 
Archive/a-different-tag 

como cuando git crea la segunda etiqueta que realmente se puso en el directorio .git/refs/tags/archive. Una vez que esté en ese estado, las recuperaciones/tiradas posteriores intentarán volver a obtener la segunda etiqueta.

Sin embargo, hay una solución simple para esto, que es ejecutar git pack-refs que amalgama los archivos de ref individuales en el archivo de texto sin formato .git/packed-refs. Una vez que ejecute, se eliminará el archivo de etiqueta individual para la primera etiqueta junto con el directorio .git/refs/tags/archive, luego la segunda etiqueta se puede obtener/extraer con éxito.