"Matthias Andree" <matthias.andree@xxxxxx> writes:
> Am 15.05.2009, 04:02 Uhr, schrieb Jeff King <peff@xxxxxxxx>:
>>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html