pokaż wszystkie tagi w dzienniku git

100

Dlaczego git log --decoratenie wyświetla więcej niż jednego tagu na zatwierdzenie?

EDYCJA : Charles Bailey wymyślił odpowiedź (przynajmniej w moim przypadku)
Zasadniczo miałem jeden tag, który wskazywał na inny tag, który wskazywał na zatwierdzenie. Z powodu tej dodatkowej warstwy pośredniej tag nie pojawiał się w dzienniku. Będę musiał to naprawić, uschnąć, naprawiając nasz skrypt tagowania, aby tagował poprawnie, lub przez jakiś skrypt powłoki voodoo, aby rekurencyjnie podążać za tagami. W każdym razie zostawię to pytanie tylko w celach informacyjnych, na wypadek, gdyby ktoś tego chciał. (Jestem nowy w przepełnieniu stosu, ale zakładam, że jest to właściwy protokół?)

... Pojawia się oryginalne pytanie ...

Backstory: Używamy GIT w pracy do kontroli źródła i mamy zasadę, że zawsze tagujemy zatwierdzenie podczas wdrażania. (W rzeczywistości jest to skrypt, który wykonuje tagi, a następnie pobiera tag z serwera). Ponieważ jest to aplikacja internetowa z oddzielnymi serwerami pomostowymi i produkcyjnymi, często oznaczamy wydanie do testowania (do testowania lub cokolwiek innego), a następnie oznaczamy to samo zatwierdzenie do produkcji.

W rzeczywistości bardzo często mamy wiele tagów na tym samym zatwierdzeniu. Byłoby bardzo miło móc zobaczyć to w dzienniku tekstowym, ale wydaje się, że to nie obsługuje. Obecnie pracuję nad tym problemem, ręcznie sprawdzając szukany tag lub uruchamiając się gitk. Chociaż oba te rozwiązania działają, wydaje mi się, że to naprawdę dziwne, git log --decorateaby domyślnie obsługiwać tylko jeden tag na zatwierdzenie.

Poszperałem w Google, ale niewiele znalazłem. Czy brakuje mi czegoś oczywistego?

PS (Właściwie używam niestandardowego ciągu formatu z %d, zgodnie ze stronami podręcznika i kilkoma szybkimi testami, jest on równoważny --decorate)

git Jonathan
źródło
12
Czy próbowałeś użyć polecenia „git log --decorate = full” (bez cudzysłowów)?
RDL
1
Jakiej wersji git używasz? W moim widzę wiele tagów.
Cascabel
@RDL: full sprawia, że ​​drukuje refs / heads / lub refs / tags / odpowiednio, prawda? Nie więcej lub mniej referencji.
Cascabel
9
Szybkie pytanie, czy tagujesz tagi, czy tagujesz zatwierdzenie? (Tagi mogą tworzyć łańcuchy, w moich testów udekorować spojrzał na znaczniki wskazujące na zatwierdzenie i znaczników wskazujących tag do popełnienia ale nie dalej niż.)
CB Bailey
1
@Charles Bailey Myślę, że mogłeś zlokalizować problem. Wypróbowałem prosty test w pracy (wersja git 1.6.3.3) i wydaje się, że działa poprawnie. Więc to nie jest kwestia wersji. Później zbadam dokładniej. Dzięki za wgląd!
Jonathan

Odpowiedzi:

17

Uwaga dotycząca tagu tagu (tagowania tagu), który jest źródłem twojego problemu, jak słusznie zauważył Charles Bailey w komentarzu:

Upewnij się, że przestudiowałeś ten wątek , ponieważ nadpisanie podpisanego tagu nie jest takie łatwe:

  • jeśli już umieściłeś tag, git tagstrona podręcznika poważnie odradzała prostą git tag -f Bzamianę nazwy znacznika „ A”

  • nie próbuj odtwarzać podpisanego tagu za pomocą git tag -f(zobacz fragment wątku poniżej)

    (chodzi o przypadek narożny, ale ogólnie dość pouczający o tagach i pochodzi od innego współpracownika SO, Jakuba Narębskiego ):

Należy pamiętać, że nazwa tagu (tag ciężki, czyli obiekt tagu) jest przechowywana w dwóch miejscach:

  • w samym obiekcie tagu jako zawartość nagłówka 'tag' (możesz to zobaczyć na wyjściu " git show <tag>", a także na wyjściu " git cat-file -p <tag>", gdzie <tag>jest tagiem ciężkim, np. v1.6.3w git.gitrepozytorium),
  • a także jest domyślną nazwą odniesienia do tagu (odniesienie w " refs/tags/*" przestrzeni nazw) wskazujące na obiekt tagu.
    Zauważ, że odniesienie do znacznika (odpowiednie odniesienie w " refs/tags/*" przestrzeni nazw) jest sprawą czysto lokalną ; co jedno repozytorium ma w „ refs/tags/v0.1.3”, inne może mieć refs/tags/sub/v0.1.3na przykład w „ ”.

Więc kiedy tworzysz podpisany tag ' A', masz następującą sytuację (zakładając, że wskazuje na jakiś zatwierdzenie)

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

Zwróć też uwagę, że „ git tag -f A A” (zauważ, że nie ma opcji powodujących, że jest to tag z adnotacją) to błąd - nie zmienia sytuacji.

Jeśli nie " git tag -f -s A A„: wiadomości, które zmuszają owerwriting tag (więc git zakłada, że wiesz co robisz), i że jeden z -s/ -a/ -mopcji służy do wymuszenia uwagami tag (utworzenie znacznika obiektu), dostaniesz następującą sytuację

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

Zwróć też uwagę, że „ git show A” spowoduje wyświetlenie całego łańcucha aż do obiektu bez znacznika ...

VonC
źródło
90 
git log --no-walk --tags --pretty="%h %d %s" --decorate=full

Ta wersja wydrukuje również komunikat o zatwierdzeniu:

 $ 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
źródło
2
Jeszcze lepiej, tworząc dla niego alias :) git config --global alias.tags "! Git log --no-walk --tags --pretty = '% h% d% s' --decorate = full"
GOXR3PLUS
1
Dzięki @ GOXR3PLUS. Musiałem zrobić: git config --global alias.tags "log --no-walk --tags --pretty = '% h% d% s' --decorate = full"
ajh158
8

Uwaga: zatwierdzenie 5e1361c z Brian bk2204M. carlson ( ) (dla git 1.9 / 2.0 Q1 2014) zajmuje się specjalnym przypadkiem związanym z dekoracją dziennika za pomocą tagów:

log: prawidłowo obchodź się z dekoracjami za pomocą zawieszonych metek

git lognie obsługiwał poprawnie dekoracji, gdy obiekt znacznika odwoływał się do innego obiektu znacznika, który nie był już odniesieniem, na przykład gdy usunięto drugi znacznik .
Zatwierdzenie nie byłoby poprawnie udekorowane, ponieważ parse_objectnie zostało wywołane na drugim tagu, a zatem jego oznaczone pole nie zostało wypełnione, co spowodowało, że żaden z tagów nie został powiązany z odpowiednim zatwierdzeniem.

Wezwij, parse_objectaby wypełnić to pole, jeśli go nie ma, aby można było wyłuskać łańcuch tagów i odpowiednio ozdobić zatwierdzenie.
Uwzględnij również testy, aby zapobiec przyszłym regresjom.

Przykład:

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
źródło