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

From: Brandon Casey <drafnel@gmail.com>
Date: Jan 3, 2013, 20:52 UTC
Message-ID: <CA+sFfMcRsD-4QwPTw6edJdUOJxdqR71oQaT9vz3QL5oCnfLTsQ@mail.gmail.com>
In-Reply-To: <50E55E94.2090401@kdbg.org>

On Thu, Jan 3, 2013 at 2:33 AM, Johannes Sixt <j6t@kdbg.org> wrote:

Show 23 quoted lines

> Am 03.01.2013 10:50, schrieb Grégory Pakosz:
>>>
>>> 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.
>
>>> 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