Показать все теги в git log

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

EDIT: Чарльз Бейли придумал ответ (по крайней мере, в моем случае)
По существу, у меня был один тег, указывающий на другой тег, указывающий на фиксацию. Из-за этого дополнительного слоя косвенности тег не показывался в журнале. Я должен исправить это, увядаю, исправляя теги script, чтобы правильно пометить, или какой-нибудь оболочкой script voodoo, чтобы рекурсивно следовать тегам. В любом случае, я оставлю этот вопрос только для справки, если кто-то захочет этого. (Я новичок в переполнении стека, но я предполагаю, что это правильный протокол?)

... Исходный вопрос следует...

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

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

Я немного погулял, но не нашел много. Мне что-то не хватает?

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

Ответ 1

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

Убедитесь, что вы изучили этот поток, поскольку переопределение подписанного тега не так просто:

Если вы уже нажали тег, git tag man page серьезно посоветовали простую git tag -f B заменить имя тега "A"
не пытайтесь воссоздать подписанный тег с git tag -f (см. извлечение потока ниже)

(речь идет о угловом футляре, но весьма поучительна в отношении тегов в целом, и она исходит от другого участника SO Jakub Narębski):

Обратите внимание, что имя тега (тяжелый тег, т.е. объект тега) хранится в двух местах:

в самом объекте тега как содержимое заголовка "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" (обратите внимание на отсутствие параметров, заставляющих его быть аннотированным тегом) - noop - это не меняет ситуацию.

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

Ответ 2

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.

Ответ 3

Примечание: зафиксировать 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