Подтвердить что ты не робот

Переименование тегов git приводит к несогласованности

После переименования тега git "1.0" на "1.5" с

git tag 1.5 1.0
git tag -d 1.0
git push origin :refs/tags/1.0

Мой репозиторий git, кажется, находится в противоречивом состоянии. Вот вывод git describe:

warning: tag '1.0' is really '1.5' here
1.0-97-g88085b2

он должен вернуть 1.5-... сейчас

вывод git fsck --tags:

Checking object directories: 100% (256/256), done.
tagged commit aad9477bba4bcf44ea34ea9693aeffc98527ff01 (1.0) in b96ce67583239e198f9e2aff5175176d65779044
Checking objects: 100% (3975/3975), done.

Как удалить ссылку на удаляемый тег? Правильно ли это переименовать теги?

Ответ 1

Я столкнулся с тем же вопросом несколько минут назад. Ни один из уже представленных ответов не касался реальной проблемы, которая избавляется от сообщения warning: tag 'foo' is really 'bar' here и получает git describe, чтобы просто перечислить новое имя тега. Это было особенно важно в моем случае, поскольку моя система сборки использует git describe для записи в сборку, какие источники были использованы для создания сборки.

Репликация проблемы

Я могу воспроизвести проблему, выполнив следующие действия:

$ git tag foo --annotate -m"original message"
$ git tag bar foo
$ git tag -d foo
$ git describe 
warning: tag 'foo' is really 'bar' here
foo

(Флаг --annotate выше, поскольку -m подразумевает --annotate, но я включил его для выделения.) Я попытался воспроизвести проблему с помощью легкого тега, но не смог этого сделать, Поэтому, чтобы воспроизвести проблему, необходима аннотация.

Фиксация проблемы

Некоторые из них включают в себя толкание вещей, которые уже подтолкнули, но я нахожусь в согласии с Дэвидом Калпом, когда он говорит:

Тем не менее, бывают случаи, когда это просто не стоит долговременной боли неточной (грязной) истории, и кратковременная боль того стоит.

Как только вы застряли с warning: tag 'foo' is really 'bar' here, вы должны сделать:

$ git tag bar bar -m"original message" --force
$ git describe 
bar

При необходимости адаптируйте, если сообщение необходимо изменить.

Чтобы удалить старый тег, если он уже был нажат:

$ git push origin :refs/tags/foo

Чтобы обновить новый тег, если он уже был нажат:

$ git push origin refs/tags/bar

Избегание проблемы

Чтобы избежать проблемы, в первую очередь вам нужно создать bar с помощью

$ git tag bar foo -m"original message"

Ответ 2

Повторить стандартную осторожность, когда кто-то предлагает переписывать историю (или в этом случае историю перехвата), - если вы можете избежать этого, не делайте этого.

Тем не менее, бывают случаи, когда это просто не стоит долговременной боли неточной (грязной) истории, и кратковременная боль того стоит.

Если это так, в следующей статье приведены необходимые шаги: Как переименовать тег, уже перенесенный в удаленный git Repo.

Основные шаги:

git tag new_tag old_tag
git push --tags
git push origin :refs/tags/old_tag
git tag -d old_tag

Ответ 3

Нет, я не думаю, что это правильный рабочий процесс для тегов в git.

Основное правило git: Не связывайтесь с тем, что вы уже нажали.

Поскольку вы уже нажали тег 1.0, вы не хотите переименовывать его на локальном уровне 1.5, а затем пытаетесь его вытолкнуть. Оставьте тэг 1.0 для потомков, создайте новый тег 1.5 и нажмите его тоже. И действительно - для чего нужны теги. Таким образом, вы можете вернуться через 6 месяцев и заново создать свое программное обеспечение в версии 1.0.