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

[Junio C Hamano <gitster@pobox.com>]

Grégory Pakosz <gpakosz@visionobjects.com> writes:

> in my use case, $ref is "refs/tags/4.0" which is an annotated tag
>
> $ git rev-parse "refs/tags/4.0"
> e941b1999906c17b59320f776d58b71fc2fcdb72

Yeah, but in that case it appears to me that you told the command to
rewrite the tag itself and the history behind the commit the tag
refers to, but the end result did not rewrite the tag itself and
left the tag pointing at the original history.

The "$rewritten" variable being empty in this codepath tells me that
the command decided that it *does* want to delete the tag, but as
J6t mentioned in his review, it is unclear to me what is expected by
the user.

If the command and the filters you gave the command decided the tag
should be removed, then not being able to delete it is a problem and
the code you patched that compares the object name of the tag and
the object name of the commit the tag refers to is certainly doing a
wrong comparison. 

But I have this suspicion that you did not want to remove the tag in
the first place.  The application of "map" shell function to obtain
$rewritten is done on the unwrapped object name by passing "$ref^0"
to rev-parse, but perhaps that "^0" is the real source of the
problem instead, so that it checks what new object the original
annotated tag was rewritten to?  If the tag object was rewritten,
either to empty to signal its removal or to a new object name, then
we do want to update-ref it, but the decision should be made on its
object name, not the object name of the commit it points at?