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

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Mar 24, 2008, 16:34 UTC
Message-ID: <47E7D818.7090501@nrlssc.navy.mil>
In-Reply-To: <alpine.LSU.1.00.0803241609540.4353@racer.site>

Johannes Schindelin wrote:

Show 26 quoted lines

> Hi,
> 
> On Mon, 24 Mar 2008, Junio C Hamano wrote:
> 
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Sun, 23 Mar 2008, Junio C Hamano wrote:
>>>
>>>> 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