etiquetas - git tag

¿Cuál es el uso recomendado de una referencia simbólica de Git?

Question

El siguiente código de shell crea correctamente una cadena de referencias simbólicas.

git symbolic-ref "first" "refs/heads/master"
git symbolic-ref "second" "first"
git symbolic-ref "nested/third" "second"
git symbolic-ref "refs/heads/fourth" "nested/third"

Y el siguiente código de shell resuelve correctamente la última referencia simbólica creada a la punta del maestro.

git show-ref "refs/heads/fourth"

Ninguno de estos casos de uso se describe en la documentación oficial ( git-symbolic-ref doc , git-show-ref doc ).

Sin embargo, lo siguiente no funciona.

 git check-ref-format --print "first"

Entonces, mis preguntas son:

• ¿Es correcto almacenar una referencia simbólica dentro del directorio refs/heads ?
• ¿Está bien encadenar referencias simbólicas?
• Como el formato de verificación-ref falla cuando se pasa "first" , ¿significa esto que no se recomienda crear una referencia simbólica al mismo nivel que "HEAD" ? ¿O tal vez este comando no pretende tratar con enlaces simbólicos?

Mi intención es obtener una comprensión clara de lo que se respalda y de que no estoy tratando de solucionar nada o beneficiarme de un error.

Answer 1

Eventualmente posted esta pregunta en la lista de correo de git development.

Junio ​​C Hamano , el principal mantenedor de git (+8700 confirmaciones) me proporcionó las siguientes respuestas.

En este momento solo hay dos tipos válidos de symrefs:

• .git / HEAD, apuntando a algún lugar bajo refs / heads / hierarchy;

• .git / refs / remotes / {algún nombre remoto} / HEAD, apuntando a algún lugar bajo refs / remotes / {el mismo nombre remoto} / hierarchy.

El código puede estar preparado para resolver similitudes recursivas, similitudes distintas de las dos clases anteriores, simulaciones que apuntan a otras partes, pero todas ellas están fuera del alcance del diseño de lo que el mecanismo pretendía respaldar. Lo que el código les hace (sin fallar) no es el diseño, sino simplemente un comportamiento indefinido.

Esto no cambiará mucho si decidimos reorganizar las jerarquías de seguimiento remoto en 1.8.0. El primero no cambiará en absoluto, y el segundo comenzará a apuntar a refs / remotes / {el mismo nombre remoto} / jefes en su lugar.

Recuerdo vagamente que tg abusó del mecanismo symref para apuntar .git / HEAD a lugares divertidos; puede que todavía lo esté haciendo, y si ese es el caso, deberíamos ampliar la lista anterior para cubrir ese uso.

Answer 2

Normalmente, los symrefs viven bajo refs refs/ - al menos, esto es lo que hace la suite git (por ejemplo, al usar git filter-tree, obtienes refs/original/... ). Algunas herramientas pueden optar por ignorar refs que no tienen refs/ prefix.

$ git symbolic-ref refs/first refs/heads/master
$ git check-ref-format --print refs/first
refs/first

Answer 3

Sería deseable que los enlaces simbólicos se puedan usar de manera más transparente y se puedan empujar también. Podrían ser una herramienta poderosa para nuevos flujos de trabajo. Actualmente, si creo un enlace simbólico y luego presiono es el servidor tendrá el hash, no el enlace en la referencia correspondiente.