Ci sono problemi con l'inserimento di una "/" in un nome di tag git per creare tag gerarchici/nidificati?

Question

Abbiamo creato un tag "2012/02/16" sul nostro repository git. Abbiamo poi notato che all'interno del Source Tree il 2012 e 01 erano rappresentati come cartelle che potevano essere ordinatamente aperte e chiuse per rivelare e nascondere i tag. Avere una gerarchia nidificata di tag sembra un bel modo per organizzare i tag invece di avere solo una lista piatta.

C'è un problema con questo?

Quando faccio un git ls-remote vedo le seguenti voci:

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

io non sono sicuro di quello che le^{} caratteri alla fine del secondo tag dire e voglio fare in modo che questo comportamento su cui ci siamo imbattuti non è qualcosa che non dovremmo fare prima di andare a sfruttarlo per ripulire i nostri tag.

Non vediamo i caratteri^{} sui nostri tag "non annidati".

Answer 1

Nessun problema, l'uso di una barra è una pratica standard, ad esempio nella disciplina "git-flow". È possibile controllare le regole di sintassi per i nomi dei tag nella pagina di manuale git-check-ref-formato (1): http://schacon.github.com/git/git-check-ref-format.html

L'accento circonflesso con staffe è qualcosa git sta cercando di parlarvi di quel tag, non qualcosa che si digitato . È possibile interpretarla utilizzando la pagina gitrevisions manuali (7): http://schacon.github.com/git/gitrevisions.html

Answer 2

L'unico problema che si incontrano è un messaggio di errore inutile se si tenta di creare un tag che si scontra con un "directory" nella gerarchia (causato direttamente dalla directory che git utilizza per memorizzare i tag in collisione):

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

Questo è improbabile che sia un problema, in pratica, si tratta di solito quando le persone cercano e fanno:

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

poi, prova e etichetta v0.0.1, che colpirà il problema precedente.

Answer 3

Oltre al problema di collisione di file/directory, è possibile riscontrare un problema di distinzione tra maiuscole e minuscole. Se stai usando un filesystem senza distinzione tra maiuscole e minuscole, come Windows e Mac OS X, allora è possibile avere tag su un repository remoto che non puoi recuperare/tirare. Ad esempio, il seguente contrasterebbe:

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

come quando git crea il secondo tag in realtà viene messo nella directory .git/refs/tags/archive. Una volta che ti trovi in ​​quello stato, i recuperi/tentativi successivi cercheranno continuamente di ottenere il secondo tag.

Tuttavia c'è una soluzione semplice per questo, che è di eseguire git pack-refs che amalgama i singoli file di riferimento nel file di testo semplice .git/packed-refs. Una volta eseguito, il singolo file di tag per il primo tag verrà rimosso insieme alla directory .git/refs/tags/archive, quindi il secondo tag può essere recuperato/estratto con successo.