Re: git-tag bug? confusing git fast-export with double tag objects

From: Jakub Narebski <jnareb@gmail.com>
Date: May 15, 2009, 13:22 UTC
Message-ID: <m34ovmlcve.fsf@localhost.localdomain>
In-Reply-To: <op.uty0pjb51e62zd@balu>

"Matthias Andree" <matthias.andree@gmx.de> writes:

> Am 15.05.2009, 04:02 Uhr, schrieb Jeff King <peff@peff.net>:

Show 35 quoted lines

>>> But what's the new signature or tag good for?
>>
>> Tagging a tag is good for saying something about the original tag, as
>> opposed to saying something about the commit that the original tag
>> points to.
> 
> Yes, I agree to that since Junio's first reply.
> 
> Clear reminder up front: this thread is *not* about tagging tagA with
> another tagB (I'll see if git fast-export has issues with that and
> perhaps  concoct a test script), but this thread *is* about replacing
> tagA with  itself.
> 
> This raises semantic and hence usability concerns.
> 
> So let's shift object relations aside for a while, no need to discuss
> what  we agree about.
> 
> Let's narrow down the discussion to signed tag objects (git tag -s/git
> tag  -u GPG-ID). They are a bit different as there's some extended
> *meaning*  that lies in the signature. I have no trouble with this. A
> <--signed-by--
> B is implemented by "git tag -s B A."
> 
> Your example is:
> 
> 	commit <--signed-by-- tag1 <--signed-by-- tag2.
> 
> Tag2 is useful in an "approved by me, too" meaning or similar. Point taken.
> 
> If I do "git tag -f -s -m three tag1 tag1" (as opposed to... tag2
> tag1),  then I'll have trouble seeing or explaning the meaning or use
> cases of the  result:
> 
> 	commit <-- signed-by-- NIL (removed) <--signed-by-- tag1.

[...]

> For this particular corner case, "git tag -f tag tag" (where I really
> use the same tag name twice) could warn along the lines [...]

[cut]

THIS IS A FEATURE, NOT A BUG.

Please note that the name of tag (heavyweight tag, i.e. tag object) is stored in two places: in the tag object itself as a contents of 'tag' header (you can see it in output of "git show <tag>" and also in output of "git cat-file -p <tag>", where <tag> is heavyweight tag, e.g. v1.6.3 in git.git repository), and also is default name of tag reference (reference in "refs/tags/*" namespace) pointing to a tag object.

So when you create signed tag 'A', you have the following situation (assuming that it points at some commit)

  35805ce   <--- 5b7b4ead  <=== refs/tags/A
  (commit)       tag A
                 (tag)
  
Please also note that "git tag -f A A" (notice the absence of options
forcing it to be an annotated tag) is a noop - it doesn't change the
situation.

If you do "git tag -f -s A A": note that you _force_ owerwriting a tag (so git assumes that you know what you are doing), and that one of -s / -a / -m options is used to force annotated tag (creation of tag object), you will get the following situation

  35805ce   <--- 5b7b4ea  <--- ada8ddc  <=== refs/tags/A
  (commit)       tag A         tag A
                 (tag)         (tag)

What is unclear about this situation? How would you want to change it: force user to use 'git tag -f -f' (I really know what I am doing)?

Note also that "git show A" would show the whole chain down to the non-tag object...

Note also that the tag _reference_ (appropriate reference in the "refs/tags/*" namespace) is purely _local_ matter; what one repository has in 'refs/tags/v0.1.3', other can have in 'refs/tags/sub/v0.1.3' for example.

-- 
Jakub Narebski
Poland
ShadeHawk on #git