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

From: Johannes Sixt <j6t@kdbg.org>
Date: Jan 3, 2013, 09:38 UTC
Message-ID: <50E55198.5080202@kdbg.org>
In-Reply-To: <7v623f18ci.fsf@alter.siamese.dyndns.org>

Am 03.01.2013 00:19, schrieb Junio C Hamano:

Show 9 quoted lines

> Grégory Pakosz <gpakosz@visionobjects.com> writes:
> 
>> So we have an annotated tag that points to a commit that is rewritten
>> to nothing as the result of the filtering. What should happen?
> 
> If the user asked to filter that tag itself, it may make sense to
> remove it, rather than keeping it pointing at the original commit,
> because the commit it used to point at no longer exists in the
> alternate history being created by filter-branch.

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.

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

-- Hannes