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

98

Почему git log --decorateне отображается более одного тега для каждой фиксации?

РЕДАКТИРОВАТЬ : Чарльз Бейли придумал ответ (по крайней мере, в моем случае).
По сути, у меня был один тег, указывающий на другой тег, указывающий на фиксацию. Из-за этого дополнительного уровня косвенности тег не отображался в журнале. Мне придется это исправить, иссушить, исправив наш сценарий тегирования для правильного тегирования, или каким-нибудь сценарием оболочки voodoo для рекурсивного следования тегам. В любом случае, я оставлю этот вопрос только для справки, если кто-то этого захочет. (Я новичок в переполнении стека, но предполагаю, что это правильный протокол?)

... Далее следует исходный вопрос ...

Предыстория: мы используем GIT на работе для управления версиями, и у нас есть политика всегда помечать коммит при развертывании. (На самом деле это сценарий, который делает теги, а затем извлекает тег на сервере). Поскольку это веб-приложение с отдельными промежуточным и производственным серверами, мы часто помечаем выпуск для постановки (для тестирования или чего-то еще), а затем помечаем тот же коммит для производства.

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

Я погуглил, но ничего не нашел. Я упускаю что-то очевидное?

PS (на самом деле я использую строку настраиваемого формата, которая %d, согласно справочным страницам и некоторым быстрым тестам, эквивалентна --decorate)

Джонатан
источник
12
Вы пробовали git log --decorate = full (без кавычек)?
RDL
1
Какую версию git вы используете? В моем я вижу несколько тегов.
Cascabel
@RDL: full позволяет выводить ссылки / головы / или ссылки / теги / в зависимости от ситуации, верно? Ни больше, ни меньше реф.
Cascabel
9
Быстрый вопрос: помечаете ли вы теги или помечаете коммит? (Теги могут образовывать цепочки, в моих тестах decorate смотрел на теги, указывающие на фиксацию, и на теги, указывающие на тег для фиксации, но не более того.)
CB Bailey
1
@Charles Bailey Я думаю, вы нашли проблему. Я попробовал простой тест на работе (git версии 1.6.3.3), и, похоже, он работает нормально. Так что это не проблема версии. Я займусь этим позже. Спасибо за понимание!
Джонатан

Ответы:

17

Обратите внимание на тег тега (тегирование тега), который является источником вашей проблемы, как правильно указал Чарльз Бейли в комментарии:

Обязательно изучите эту цепочку , поскольку переопределить подписанный тег не так просто:

  • Если вы уже вставили тег, на 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" покажет всю цепочку до объекта без тегов ...

VonC
источник
86
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.
Марчелло де Салес
источник
2
Еще лучше создать для него псевдоним :) git config --global alias.tags "! Git log --no-walk --tags --pretty = '% h% d% s' --decorate = full"
GOXR3PLUS
1
Спасибо @ GOXR3PLUS. Пришлось сделать: git config --global alias.tags "log --no-walk --tags --pretty = '% h% d% s' --decorate = full"
ajh158
8

Примечание: коммит 5e1361c от brian m. carlson ( bk2204) (для git 1.9 / 2.0 Q1 2014) имеет дело с особым случаем оформления журнала тегами:

log: правильно обрабатывать украшения с помощью связанных тегов

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
VonC
источник