mostra tutti i tag nel log di git

Perché git log --decoratenon mostra più di un tag per commit?

EDIT : Charles Bailey ha trovato la risposta (almeno nel mio caso)
Essenzialmente, avevo un tag che puntava a un altro tag che puntava al commit. A causa di questo ulteriore livello di riferimento indiretto, il tag non veniva visualizzato nel registro. Dovrò risolvere questo problema, avvizzire aggiustando il nostro script di tagging per taggare correttamente, o da qualche voodoo di script di shell per seguire ricorsivamente i tag. Ad ogni modo, lascio questa domanda solo per riferimento nel caso qualcuno lo desideri. (Sono nuovo nello stack overflow, ma presumo che sia il protocollo corretto?)

... Segue domanda originale ...

Backstory: usiamo GIT al lavoro per il controllo del codice sorgente e abbiamo una politica di taggare sempre un commit quando distribuiamo. (In realtà è uno script che esegue tag e quindi estrae il tag sul server). Poiché si tratta di un'applicazione Web con server di staging e di produzione separati, spesso taggiamo una versione per la gestione temporanea (per il test o altro) e successivamente taggiamo lo stesso commit per la produzione.

Quindi in realtà è molto spesso che abbiamo più tag sullo stesso commit. Sarebbe molto bello poterlo vedere nel registro di testo, ma non sembra supportarlo. Al momento sto risolvendo il problema controllando manualmente il tag che sto cercando o attivando gitk. Sebbene entrambe queste soluzioni funzionino, mi sembra che sia davvero stranogit log --decorate supportare solo un tag per commit per impostazione predefinita.

Ho cercato su Google, ma non ho trovato molto. Mi sto perdendo qualcosa di ovvio?

PS (in realtà uso una stringa di formato personalizzata con %d, secondo le pagine man e alcuni test rapidi, è equivalente a --decorate)

git

— Jonathan
fonte

Hai provato "git log --decorate = full" (meno virgolette)?

— RDL

Quale versione di git stai usando? Vedo più tag perfettamente nel mio.

— Cascabel

@RDL: full fa stampare refs / head / o refs / tag / come appropriato, giusto? Non più o meno ref.

— Cascabel

Domanda veloce, tagghi i tag o tagghi il commit? (I tag possono formare catene, nei miei test decorare ha guardato tag che puntano a un commit e tag che puntano a un tag a un commit ma non oltre.)

— CB Bailey

@Charles Bailey Penso che tu possa aver individuato il problema. Ho provato un semplice test al lavoro (versione git 1.6.3.3) e sembra funzionare bene. Quindi non è un problema di versione. Indagherò più tardi. Grazie per l'intuizione!

— Jonathan

Risposte:

Nota sul tag del tag (taggare un tag), che è all'origine del tuo problema, come Charles Bailey correttamente sottolineato nel commento:

Assicurati di studiare questo thread , poiché sovrascrivere un tag firmato non è così facile:

se hai già inserito un tag, la git tagpagina man sconsiglia seriamente git tag -f Bdi sostituire semplicemente il nome di un tag "A "
non provare a ricreare un tag firmato con git tag -f (vedi l'estratto del thread di seguito)

(si tratta di un caso d'angolo, ma piuttosto istruttivo sui tag in generale, e proviene da un altro collaboratore di SO Jakub Narębski ):

Tieni presente che il nome del tag (tag pesante, ovvero oggetto tag) è memorizzato in due posizioni:

nell'oggetto tag stesso come contenuto dell'intestazione 'tag' (puoi vederlo nell'output di " git show <tag>" e anche nell'output di " git cat-file -p <tag>", dove <tag>è il tag pesante, ad esempio v1.6.3nel git.gitrepository),

ed è anche il nome predefinito del riferimento al tag (riferimento nello refs/tags/*spazio dei nomi " ") che punta a un oggetto tag.
Notare che il riferimento al tag ( riferimento appropriato nello refs/tags/*spazio dei nomi " ") è puramente locale ; quello che un repository ha in " refs/tags/v0.1.3", un altro può avere in " refs/tags/sub/v0.1.3" per esempio.

Quindi, quando crei un tag firmato ' A', hai la seguente situazione (supponendo che punti a qualche commit)

  35805ce   <--- 5b7b4ead  <=== refs/tags/A
  (commit)       tag A
                 (tag)

Nota anche che " git tag -f A A" (nota l'assenza di opzioni che lo costringono ad essere un tag annotato) è un noop - non cambia la situazione.

Se lo fai " git tag -f -s A A": nota che la forza owerwriting un tag (in modo git presuppone che si sa cosa si sta facendo), e che uno dei -s/ -a/ -mopzioni viene utilizzato per forzare tag annotated (creazione di oggetti tag), si otterrà il seguente situazione

  35805ce   <--- 5b7b4ea  <--- ada8ddc  <=== refs/tags/A
  (commit)       tag A         tag A
                 (tag)         (tag)

Nota anche che " git show A" mostrerebbe l'intera catena fino all'oggetto senza tag ...

— VonC
fonte

git log --no-walk --tags --pretty="%h %d %s" --decorate=full

Questa versione stamperà anche il messaggio di commit:

 $ git log --no-walk --tags --pretty="%h %d %s" --decorate=full
3713f3f  (tag: refs/tags/1.0.0, tag: refs/tags/0.6.0, refs/remotes/origin/master, refs/heads/master) SP-144/ISP-177: Updating the package.json with 0.6.0 version and the README.md.
00a3762  (tag: refs/tags/0.5.0) ISP-144/ISP-205: Update logger to save files with optional port number if defined/passed: Version 0.5.0
d8db998  (tag: refs/tags/0.4.2) ISP-141/ISP-184/ISP-187: Fixing the bug when loading the app with Gulp and Grunt for 0.4.2
3652484  (tag: refs/tags/0.4.1) ISP-141/ISP-184: Missing the package.json and README.md updates with the 0.4.1 version
c55eee7  (tag: refs/tags/0.4.0) ISP-141/ISP-184/ISP-187: Updating the README.md file with the latest 1.3.0 version.
6963d0b  (tag: refs/tags/0.3.0) ISP-141/ISP-184: Add support for custom serializers: README update
4afdbbe  (tag: refs/tags/0.2.0) ISP-141/ISP-143/ISP-144: Fixing a bug with the creation of the logs
e1513f1  (tag: refs/tags/0.1.0) ISP-141/ISP-143: Betterr refactoring of the Loggers, no dependencies, self-configuration for missing settings.

— Marcello de Sales
fonte

Ancora meglio creare un alias per esso :) git config --global alias.tags "! Git log --no-walk --tags --pretty = '% h% d% s' --decorate = full"

— GOXR3PLUS

Grazie @ GOXR3PLUS. Dovevo fare: git config --global alias.tags "log --no-walk --tags --pretty = '% h% d% s' --decorate = full"

— ajh158

Nota: il commit 5e1361c di brian m. carlson ( bk2204) (per git 1.9 / 2.0 Q1 2014) si occupa di un caso speciale in termini di decorazione del registro con tag:

log: gestire correttamente le decorazioni con tag concatenati

git lognon gestiva correttamente le decorazioni quando un oggetto tag faceva riferimento a un altro oggetto tag che non era più un riferimento, come quando il secondo tag è stato eliminato .
Il commit non sarebbe stato decorato correttamente perché parse_objectnon era stato chiamato sul secondo tag e quindi il suo campo con tag non era stato compilato, con il risultato che nessuno dei tag era associato al commit pertinente.

Chiama parse_objectper compilare questo campo se è assente in modo che la catena di tag possa essere dereferenziata e il commit possa essere adeguatamente decorato.
Includere anche test per prevenire future regressioni.

Esempio:

git tag -a tag1 -m tag1 &&
git tag -a tag2 -m tag2 tag1 &&
git tag -d tag1 &&
git commit --amend -m shorter &&
git log --no-walk --tags --pretty="%H %d" --decorate=full

— VonC
fonte