Re: [PATCH 2/2] filter-branch.sh: support nearly proper tag name filtering

Johannes Schindelin wrote:

Hi,

On Mon, 24 Mar 2008, Junio C Hamano wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

On Sun, 23 Mar 2008, Junio C Hamano wrote:

quoted

If you tell filter-branch to filter a branch A and a tag T, as the 
command is advertised to rewrite positive refs that were given from 
the command line, isn't it natural to expect that the command would 
attempt its best effort to rewrite such a tag object?

The thing is: signed tags cannot be rewritten.

I know that, and you know I know that if you read what you responded 
again ;-)

And I think stripping of gpg signature part is a reasonable best effort 
for the command, _when_ the user told a signed tag to be rewritten.

Yes.

BUT.

You can say "--all", and I actually expect quite a few people to do 
exactly that.  And then you cannot really say "the user explicitely asked 
to have that signed tag rewritten".

That sounds like saying that specifying "HEAD" as the revision (_and_
using --tag-name-filter) is not explicitly asking for tags to be rewritten.
?

Aside from that, wouldn't the signed tag currently be rewritten? With current
git, if I have a signed tag named "my_signed_release", and I can verify its
authenticity using 'git tag -v my_signed_release', and then I run filter-branch
with '--tag-name-filter cat', my previously signed tag is replaced with a light
weight tag and of course 'git tag -v my_signed_release' fails.

I don't see how the situation for signed tags changes much. The current state
is that the signature cannot be preserved, so if "new" signed tags are desired,
they must be handled specially. On the other hand, the situation for unsigned
tags becomes much easier, assuming you want to retain the tag properties. Aren't
unsigned tags more common than signed ones?

So right now, tags matching the refspec are rewritten. They are currently
rewritten with a lightweight tag. I don't think you have explained what is
wrong with defaulting to creating a new tag object which retains as much
information from the original tag object as possible. In other words, why
would a user _not_ expect that the tag filter would preserve the tag message?

Can you describe some scenario where a user would use --tag-name-filter and
would prefer the creation of new light-weight tags over tag objects? I can't
imagine one in my own situation. Maybe there is some example in your own
workflow?

-brandon