Qual è l'utilizzo consigliato di un riferimento simbolico Git?

Question

Il seguente codice shell crea correttamente una catena di riferimenti simbolici

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"

E il seguente codice shell risolve correttamente l'ultimo riferimento simbolico creato alla punta del master.

git show-ref "refs/heads/fourth"

Nessuno di questi casi d'uso è descritto nella documentazione ufficiale (git-simbolico-rif doc, git-show-ref doc).

Tuttavia, quanto segue non funziona

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

Quindi, le mie domande sono:

• È corretto memorizzare un riferimento simbolico all'interno del file refs/heads rubrica?
• È corretto concatenare riferimenti simbolici?
• Poiché il formato check-ref fallisce quando viene superato "first", ciò significa che non è consigliabile creare un riferimento simbolico allo stesso livello di "HEAD"?O forse questo comando non è destinato a gestire i collegamenti simbolici?

Il mio intento è quello di avere una chiara comprensione di ciò che è supportato e che non sto lavorando su nulla o traendo vantaggio da un bug.

Answer 1

Alla fine l'ho fatto pubblicato questa domanda alla mailing list di sviluppo git.

Junio ​​C Hamano, il principale manutentore di Git (+8700 commit) mi ha fornito le seguenti risposte.

Ci sono solo due tipi validi di Symrefs in questo momento:

• .git/HEAD, che punta da qualche parte sotto refs/heads/gerarchia;

• .git/refs/remotes/{un nome remoto}/testa, indicando da qualche parte sotto Refs/Remotes/{lo stesso nome remoto}/gerarchia.

Il codice può essere pronto a risolvere Symrefs ricorsivi, Symrefs diversi dai due tipi sopra, Symrefs che indicano altrove, ma tutti sono al di fuori dell'ambito di progettazione di ciò che il meccanismo aveva lo scopo di supportare.Ciò che il codice fa per loro (senza crash) non è il design, ma semplicemente un comportamento indefinito.

Questo non cambierà molto se decidiamo di riorganizzare le gerarchie di monitoraggio remoto in 1.8.0.Il primo non cambierà affatto e il secondo inizierà invece a puntare su Refs/Remotes/{lo stesso nome remoto}/Heads Gerarchy.

Ricordo vagamente TG abusato del meccanismo Symref per puntare .Git/testa in luoghi divertenti;Potrebbe ancora farlo, e in tal caso dovremmo estendere l'elenco sopra per coprire tale utilizzo.

Answer 2

Normalmente, Symrefs vive sotto refs/ -Almeno, questo è ciò che fa la suite Git (ad esempio quando si utilizza il filtro Git, ottieni refs/original/...). Alcuni strumenti possono scegliere di ignorare i ref che non hanno il refs/ prefisso.

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

Answer 3

Sarebbe auspicabile che i collegamenti simbolici possano essere usati in modo più trasparente e possono anche essere spinti. Potrebbero essere uno strumento potente per nuovi flussi di lavoro. Attualmente, se creo un collegamento simbolico e quindi push è il server avrà l'hash non il collegamento nel riferimento corrispondente.