Git retagging вменяемых и безумных советов - часть 2

Question

Когда я читал о переименовании тегов git, многие люди указывали на чтение this :

Что делать, если вы пометили неправильный коммит и захотитеповторно пометить?

Если вы никогда ничего не выдвигали, просто пометите это.Используйте «-f» для замены старого.И все готово.

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

Нормальная вещь.Просто признай, что ты облажался, и используй другое имя.Другие уже видели одно имя тега, и если вы сохраняете одно и то же имя, вы можете оказаться в ситуации, когда два человека имеют «версию X», но на самом деле они имеют разные «X».Так что просто назовите это «X.1» и покончите с этим.

Безумная вещь.Вы действительно хотите также назвать новую версию «Х», хотя другие уже видели старую.Так что просто используйте git tag -f снова, как если бы вы еще не опубликовали старый.

Однако Git не изменяет (и не должен) изменять теги позади пользователей.Поэтому, если кто-то уже получил старый тег, выполнение git pull на вашем дереве не должно просто заставить его перезаписать старый.

Если кто-то получил от вас тег выпуска, вы не можете просто изменитьпометьте их, обновив свой собственный.Это большая проблема безопасности , в которой люди ДОЛЖНЫ быть в состоянии доверять своим именам тегов.Если вы действительно хотите сделать безумную вещь, вам нужно просто признать это и сказать людям, что вы все испортили.

Что ж, при повторной привязке я задал более ранний вопрос, если вам интересно - Git retagging вменяемые и безумные советы - часть 1 , однако, это не требуется.Я только что заковал вопрос, так как контекст один и тот же.

Итак, мой вопрос

У меня есть 2 локальных репо одного пульта - репо 1 и репо 2.

Шаг1: Создать аннотированный тег в репо1 по имени, скажем X.

Шаг 2: Нажмите для удаленного доступа.

Шаг 3: Репо 2 извлекает тег.

Шаг 4: Repo 1 удаляет тег X и создает еще один тег X, но с другим сообщением на этот раз.

Шаг 5: нажмите для удаленного доступа.

Шаг 6: В repo2, git pull --tags,обновляет тег X.

Как это возможно?Как отмечалось выше, Git не должен делать это - то есть обновление тега?

Answer 1

Это может быть возможно, если ваш repo2 каким-то образом настроен на удаление тегов с пульта.Например, может быть fetch.pruneTags=true в ~/.gitconfig или в другом месте.Если вы хотите выяснить это, запустите git config -l | grep fetch и посмотрите, что он будет печатать.

Сокращение тегов не является настройкой по умолчанию, поэтому не рекомендуется ретранслировать это.Вы можете использовать его в своих контролируемых репозиториях, но не ожидайте, что другие разработчики включат prune-tags.

Подробная информация содержится в документации :

Поскольку поддержание актуальности как веток, так и тегов на пульте является распространенным вариантом использования, опция --prune-tags может поставляться вместе с --prune для удаления локальных тегов, которые не существуют на пульте,и принудительно обновите те теги, которые отличаются.Удаление тегов также можно включить с помощью fetch.pruneTags или remote..pruneTags в конфигурации.См. Git-config.

Опция --prune-tags эквивалентна объявлению refs / tags / : refs / tags / в refspecs удаленного устройства.Это может привести к некоторым, казалось бы, странным взаимодействиям:

Answer 2

Так что, если кто-то уже получил старый тег,

Это ваш шаг 3.

не должен просто заставлять их перезаписывать старый.

Ну, это не так, как он все еще содержит старый тег, не так ли?

Если кто-то получил от вас метку релиза, вы не можете просто изменить метку для него, обновив свою собственную.

Так действует старый - всехорошо.Вы не можете изменить тег после его нажатия.