Вы не можете. Но это не имеет значения, потому что нет смысла.
Что делает git filter-branch, так это добавляет новые коммиты в хранилище. В общем, вы берете существующий репозиторий, полный коммитов, идентифицируете один или несколько «плохих» и говорите Git: Для каждого коммита извлеките этот коммит, исправьте его, если он плохой, и затем превратите его в новый коммит . Если новый коммит на 100% идентичен, бит за битом, оригиналу - если фильтр вообще не вносил изменений - Git завершает повторное использование оригинального коммита. В противном случае Git делает новый и улучшенный коммит, в котором исправлено все, что было не так с оригиналом, и / или ссылается на другие новые коммиты вместо старых старых.
Ваша задача состоит в создании нового тега (тега с комментариями типа), который ссылается на тот же старый существующий коммит, что и предыдущий тег (также тега с комментариями типа). Вам не нужно добавлять новые коммиты.
Чтобы делать то, что вы хотите, просто сделайте новый тег. Вам нужно сначала переименовать или удалить старый аннотированный тег, чтобы убрать его с дороги. Нет команды переименовать тег (если он распакован, вы можете обмануть, но если он был упакован, это не сработает), так что это означает, что вам необходимо удалить старый тег. Обязательно сначала сохраните целевой хэш commit , поскольку удаление тега сделает невозможным 1 повторный поиск.
Таким образом:
git rev-parse existing-tag^{commit}
чтобы получить идентификатор хеша коммита, затем:
git tag -d existing-tag
, то:
git tag -a existing-tag hash
где hash - это большой некрасивый идентификатор хеша, напечатанный git rev-parse.
1 Технически, вы можете найти его, но это слишком сложно, особенно потому, что git fsck не будет сохранять объекты тегов без ссылок в каталог lost-found, как это делает для коммитов и блобов без ссылок.