показати всі теги в журналі git

Чому git log --decorateна коміті не відображається більше одного тегу?

EDIT : Чарльз Бейлі запропонував відповідь (принаймні в моєму випадку)
По суті, у мене був один тег, який вказував на інший тег, який вказував на коміт. Через цей додатковий рівень опосередкованості тег не відображався в журналі. Мені доведеться це виправити, в’янути, виправляючи наш скрипт тегування, щоб правильно мітити, або якийсь скрипт оболонки вуду, щоб рекурсивно слідувати за тегами. У будь-якому випадку, я залишу це питання лише для довідки на випадок, якщо хтось цього захоче. (Я новачок у стеку, але я вважаю, що це правильний протокол?)

... Оригінальне запитання слідує ...

Передісторія: Ми використовуємо GIT на роботі для контролю джерел, і ми маємо політику постійного позначення коміту під час розгортання. (Це насправді скрипт, який робить теги, а потім витягує тег на сервері). Оскільки це веб-додаток з окремими проміжними та робочими серверами, ми часто позначаємо випуск для проміжного етапу (для тестування чи чогось іншого), а потім пізніше додаємо те ж коміт для виробничого.

Тож насправді дуже часто ми маємо кілька тегів на одному коміті. Було б дуже приємно бачити це в текстовому журналі, але, схоже, це не підтримує. Зараз я вирішую проблему, перевіряючи вручну тег, який я шукаю, або запускаючи gitk. Хоча обидва ці рішення працюють, мені здається, що насправді дивно git log --decorateпідтримувати лише один тег за комітом за замовчуванням.

Я кілька разів гуглив, але не знайшов багато. Мені не вистачає чогось очевидного?

PS (я фактично використовую рядок нестандартного формату %d, відповідно до сторінок керівництва та деяких швидких тестів, це еквівалентно --decorate)

Зверніть увагу на тег тегу (тегування тегу), який є джерелом вашої проблеми, як правильно зазначив Чарльз Бейлі в коментарі:

Обов’язково вивчіть цей потік , оскільки замінити підписаний тег не так просто:

• якщо ви вже натиснули тег, git tagсторінка користувача серйозно не рекомендує git tag -f Bзамінювати назву тегу " A"

• не намагайтеся відтворити підписаний тег за допомогою git tag -f(див. витяг потоку нижче)

  (мова йде про кутовий випадок, але цілком повчальний про теги загалом, і це походить від іншого співробітника SO, Якуба Нарембського ):

Зверніть увагу, що ім'я тегу (важкий тег, тобто об'єкт тегу) зберігається у двох місцях:

• в самому об'єкті тегу як вміст заголовка 'tag' (ви можете побачити його у виведенні " git show <tag>", а також у виведенні " git cat-file -p <tag>", де <tag>є важкий тег, наприклад, v1.6.3у git.gitсховищі),
• а також є типовою назвою посилання на тег (посилання в " refs/tags/*" просторі імен), що вказує на об'єкт тегу.
  Зверніть увагу, що посилання на тег (відповідне посилання у " refs/tags/*" просторі імен) є суто місцевим ; те, що одне сховище має в ' refs/tags/v0.1.3', інше може мати в ' refs/tags/sub/v0.1.3', наприклад.

Отже, коли ви створюєте підписаний тег ' A', ви маєте наступну ситуацію (припускаючи, що він вказує на деякий коміт)

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

Також зауважте, що " git tag -f A A" (зауважте відсутність опцій, що змушують його бути анотованим тегом) - це неприємність - це не змінює ситуацію.

Якщо ви зробите " git tag -f -s A A": зауважте, що ви примусово пишете тег (тому git припускає, що ви знаєте, що робите), і що один з -s/ -a/ -mпараметрів використовується для примусового анотованого тегу (створення об'єкта тегу), ви отримаєте наступна ситуація

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

Також зверніть увагу, що " git show A" показало б весь ланцюжок до об'єкта, що не мітить ...

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

Ця версія також надрукує повідомлення про коміт:

 $ 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.

Примітка: коміт 5e1361c від brian m. carlson ( bk2204) (для git 1.9 / 2.0 Q1 2014) розглядає особливий випадок щодо оформлення колоди тегами:

журнал: правильно обробляти прикраси з прикутими бирками

git logнеправильно обробляв прикраси, коли об’єкт тегу посилався на інший об’єкт тегу, який більше не був посиланням, наприклад, коли другий тег був видалений .
Фіксація не буде оформлена правильно, оскільки parse_objectїї не було викликано для другого тегу, а тому його теговане поле не було заповнене, в результаті чого жоден з тегів не був пов’язаний з відповідним комітом.

Зателефонуйте, parse_objectщоб заповнити це поле, якщо воно відсутнє, щоб ланцюжок тегів можна було розмежовувати і коміт правильно оформляти.
Включіть також тести, щоб запобігти майбутнім регресам.

Приклад:

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