Quelle est l’utilisation recommandée d’une référence symbolique Git ?

Question

Le code shell suivant crée correctement une chaîne de références symboliques

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"

Et le code shell suivant résout correctement la dernière référence symbolique créée à la pointe du maître.

git show-ref "refs/heads/fourth"

Aucun de ces cas d'utilisation n'est décrit dans la documentation officielle (git-symbolic-ref doc, doc git-show-ref).

Cependant, ce qui suit ne fonctionne pas

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

Donc mes questions sont :

• Est-il possible de stocker une référence symbolique dans le refs/heads répertoire ?
• Est-il acceptable d'enchaîner des références symboliques ?
• Comme le format check-ref échoue lors de sa réussite "first", cela signifie-t-il qu'il n'est pas recommandé de créer une référence symbolique au même niveau que "HEAD"?Ou peut-être que cette commande n'est pas destinée à gérer les liens symboliques ?

Mon intention est de bien comprendre ce qui est pris en charge et de savoir que je ne contourne rien et que je ne profite pas d'un bug.

Answer 1

J'ai finalement posté cette question à la liste de diffusion de développement git.

Junio ​​C Hamano, le responsable principal de Git (+8 700 commits) m'a fourni les réponses suivantes.

Il n'y a que deux types de symRefs valides en ce moment:

• .git/HEAD, pointant quelque part sous la hiérarchie refs/heads/ ;

• .Git / Refs / Remotes / {un nom de télécommande} / tête, pointant quelque part sous Refs / Remotes / {le même nom de télécommande} / hiérarchie.

Le code peut être prêt à résoudre des symRefs récursifs, symRefs autres que les deux types ci-dessus, SymRefs qui pointent ailleurs, mais tous sont en dehors de la portée de conception de ce que le mécanisme était destiné à soutenir.Ce que le code leur fait (sans s'écraser) n'est pas la conception, mais simplement un comportement non défini.

Cela ne changera pas beaucoup si nous décidons de réorganiser les hiérarchies de suivi à distance en 1.8.0.Le premier ne changera pas du tout, et le second commencera à pointer des références / télécommandes / {la même hiérarchie de la même télécommande} / Heads.

Je me souviens vaguement que TG a abusé du mécanisme SymRef pour pointer .git / head à des endroits drôles;Il peut toujours le faire, et si tel est le cas, nous devons étendre la liste ci-dessus pour couvrir cette utilisation.

Answer 2

Normalement, les symrefs vivent sous refs/ — du moins, c'est ce que fait la suite git (par exemple, lorsque vous utilisez git filter-tree, vous obtenez refs/original/...).Certains outils peuvent choisir d'ignorer les références qui n'ont pas le refs/ préfixe.

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

Answer 3

Il serait souhaitable que les liens symboliques puissent être utilisés de manière plus transparente et puissent également être poussés.Ils pourraient constituer un outil puissant pour de nouveaux flux de travail.Actuellement, si je crée un lien symbolique puis que je le pousse, le serveur aura le hachage et non le lien dans la référence correspondante.