Re: git filter-branch doesn't dereference annotated tags

On Thu, Jan 3, 2013 at 2:33 AM, Johannes Sixt [off-list ref] wrote:

Am 03.01.2013 10:50, schrieb Grégory Pakosz:

quoted

quoted

IOW, if the command was something like

  git filter-branch ...filter options... -- v1.0 master ...

and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be
deleted if the commit it points to goes away. But if the commit did not
go away, but was rewritten, then it is equally reasonable to expect that
the tag is also rewritten. But I don't think that we currently do the
latter.

When the commit doesn't go away, the tag is currently being rewritten properly.

Indeed, but only if a --tag-name-filter was specified.

quoted

quoted

Therefore, IMO, a change that implements the former behavior should also
implement the latter behavior.

The patch in my latest email does both. (yet lacks unit tests for now)

If it deletes a tag only when --tag-name-filter was specified, than that
should be fine.

Hmm, if a tag name filter _other_ than 'cat' is supplied, I think a
user will expect that the original tags will _not_ be touched, and
especially not deleted.

Rather than blindly deleting the original tag ref, maybe we should
still call the user's tag name filter, and then attempt to delete the
"new" name provided by the filter, if it exists.  If the filter was
'cat', then the new and old names will be the same.

-Brandon