В нашем репозитории git имеется несколько аннотированных тегов. У старых тегов есть фальшивые сообщения, которые мы хотели бы обновить, чтобы быть в нашем новом стиле.
% git tag -n1
v1.0 message
v1.1 message
v1.2 message
v2.0 Version 2.0 built on 15 October 2011.
В этом примере мы хотели бы, чтобы сообщения v1.x выглядели как сообщение v2.0. Кто-нибудь знает, как мы это сделаем?
git tag <tag name> <tag name>^{} -f -m "<new message>"
Это создаст новый тег с тем же именем (путем перезаписи оригинала).
Чтобы обновить сложное сообщение, просто укажите параметр аннотированного тега с помощью -a или параметр тега со -s с -s:
git tag <tag name> <tag name>^{} -f -a
Откроется редактор с содержимым вашего старого тега сообщения.
git tag <tag name> <tag name>^{} -f -a
Это улучшение по сравнению с Andy и ответы Эрика Ху. Их ответы создадут новый объект тега, который ссылается на старый объект тега, где оба они будут иметь одинаковое имя тега.
<tag name>^{} разрешит тег/ссылку до тех пор, пока не найдет первый хэш-код фиксации.
Вы можете сделать это, удалив тэг и воссоздав его, спуская дату и автора:
<Предварительно > <код → git tag -d < tag-name → [GIT_COMMITTER_DATE = < original-commit-date > ] \ > [GIT_AUTHOR_NAME = < оригинал-author-name > ] \ > git tag < tag-name > [Совершить] Код >На основе ответа Sungram (первоначально предлагаемого в качестве редактирования):
Это улучшение по сравнению с Энди и Эрик Ху. Их ответы создадут новый объект тега, который ссылается на старый объект тега, и оба будут иметь одинаковое имя.
Чтобы проиллюстрировать это, рассмотрите следующее:
<Предварительно > <код → git tag tag1 tag1 -f -a # принят ответ > git rev-list --объекты -g --no-walk --все [пример вывода:] 6bdcc347fca041a5138f89fdf5276b3ebf9095d5 260ab7928d986472895b8c55e54569b3f3cb9517 tag1 a5797673f610914a45ef7ac051e3ee831a6e7c25 tag1 f22d6308c3cd330a3b0d86b9bf05562faf6b6f17 > git show tag1 tag tag1 Tagger: [tagger] Дата: [дата обновленного тега] [Обновлено описание] tag tag1 Tagger: [tagger] Дата: [дата оригинальной метки] [Исходное описание] [отмеченные детали фиксации] Код >Используя < имя тега > ^ {}, поскольку второй аргумент тега git вместо этого удалит все предыдущие теги с тем же именем.
Рассмотрим продолжение предыдущего сеанса терминала:
<Предварительно > <код → git tag tag1 tag1 ^ {} -f -a # предлагаемое улучшение > git rev-list --объекты -g --no-walk --все [пример вывода:] 6bdcc347fca041a5138f89fdf5276b3ebf9095d5 75f02acacfd7d91d55b5bcfdfb1f00aebeed15e3 tag1 f22d6308c3cd330a3b0d86b9bf05562faf6b6f17 > git show tag1 tag tag1 Tagger: [tagger] Дата: [дата обновленного тега] [Обновлено описание] [отмеченные детали фиксации] Код >Наконец, если вы хотите сохранить дату исходного тега в качестве даты обновленного тега, используйте некоторую магию awk (или аналогичного) или просто вставьте нужную дату. Ниже приведена подстановка для второго примера (иначе исходная дата будет потеряна из-за переопределения):
<Предварительно > <код → GIT_COMMITTER_DATE = "$ (git show tag1 | # получить информацию о каскаде тегов, включая дату оригинала исходного тега > awk '{ > if ($ 1 == "Date:" ) { > print substr ($ 0, индекс ($ 0, $3)) > } > } '| # извлечение всех дат из информации > хвост -2 | head -1) "` # получить вторую до последней даты, так как последняя является датой фиксации \ > git tag tag1 tag1 ^ {} -a -f # наконец, обновить сообщение тега, но сохранить дату старого → git rev-list --объекты -g --no-walk --все 6bdcc347fca041a5138f89fdf5276b3ebf9095d5 e18c178f2a548b37799b100ab90ca785af1fede0 tag1 f22d6308c3cd330a3b0d86b9bf05562faf6b6f17 > git show tag1 tag tag1 Tagger: [tagger] Дата: [дата оригинальной метки] [Обновлено описание] [отмеченные детали фиксации] Код >Литература:
В качестве альтернативы обновлению тегов вы можете просто удалить их и создать их снова. Как оказалось, обновление просто добавляет новый тег и указывает на старое, или, альтернативно, просто неявно удаляет старый и создает новый, чтобы указать на одно и то же сообщение.
Вы можете добиться этого, выпустив:
<Предварительно > <код → git tag -d < tag-name → [GIT_COMMITTER_DATE = < original-commit-date > ] \ > [GIT_AUTHOR_NAME = < оригинал-author-name > ] \ > git tag < tag-name > [Совершить] Код >Здесь [optional] - необязательное поле; <required> - обязательное поле.
Конечно, вы можете добавить любые флаги после команды git tag, которую вы обычно делаете.
Решение @Andy
git tag <tag-name> <tag-name> -f -a
неверно. После этого с помощью
git show
мы увидим теги стека с тем же именем.
Он добавляет новый тег с тем же именем тега и новым сообщением в commit <tag-name>. Но он не удаляет старый тег. Это особый случай этой команды:
git tag [<commit> | <old-tag>] <tag-name>
Но только <old-tag> совпадает с <tag-name>.
Правильное решение простое, только тег обновления в порядке.
git tag <tag-name> -f -a
Помните, что здесь ОДИН.
Если нам нужен тег изменения, который не является HEAD, нам нужен дополнительный аргумент <commit>.
git tag <commit> <tag-name> -f -a
мы хотели бы, чтобы сообщения v1.x выглядели как сообщения v2.0
В Git 2.17 (Q2 2018) будет альтернатива созданию нового тега с тегом git tag <tag name> <tag name> -f -m "<new message>", поскольку " git tag " изучил явное --edit " --edit ", позволяющий дополнительно редактировать сообщение, переданное через " -m " и " -f ".
См. Коммит 9eed6e4 (06 февраля 2018 г.) Николаса Морея-Шаземартина (nmorey).
(Объединено Junio C Hamano - gitster - в коммите 05d290e, 6 марта 2018 г.)
tag: добавить--edit
Добавьте --edit которая позволяет изменять сообщения, предоставляемые -m или -f, так же, как git commit --edit делает git commit --edit.
Используя вышеприведенные ответы, это мой одноадресный псевдоним для .gitconfig. Заменяет существующий тег и сохраняет дату фиксации.
[alias]
tm = "!sh -c 'f() { export GIT_COMMITTER_DATE=$(git log -1 --format=%ci $0); git tag -f -a $0 $0^{}; }; f '"
Улучшения?
Вам нужно будет пометить еще раз, используя флаг силы -f.
git tag v1.0 -f -m "actual message"