Re: [RFC] tag-ref and tag object binding

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

Jeff King <peff@peff.net> writes:

>> I don't think that an addition like this would get in the way of any
>> existing git workflow, and should be backwards-compatible right?
>
> Doesn't this already exist?
>
>   $ git cat-file tag v2.0.0
>   object e156455ea49124c140a67623f22a393db62d5d98
>   type commit
>   tag v2.0.0
>   tagger Junio C Hamano <gitster@pobox.com> 1401300269 -0700
>
>   Git 2.0
>   -----BEGIN PGP SIGNATURE-----
>   [...]
>   -----END PGP SIGNATURE-----
>
> Tag objects already have a "tag" header, which is part of the signed
> content. If you use "git verify-tag -v", you can check both that the
> signature is valid and that the tag is the one you are expecting.

Another thing worth mentioning is that "fsck" does not insist that
refs/tags/$NAME must have a "tag" line that says "tag $NAME", and
that is a very deliberate design decision.  A project may want to
allow multiple people tag the same commit with the same tagname and
publish all of them in the same ref hierarchy.  For example, while I
am away, Peff may make an emergency maintenance release and tag it
like so:

    $ git tag -s -m 'Git v2.7.1' v2.7.1 master
    $ git push $there tags/v2.7.1:tags/peff/v2.7.1 master

and announce to the list that he has cut a release, and published
his signed tag as peff/v2.7.1 in the public repository.  While
everybody in the project trusts Peff as much as they trust me, I
would still want to sign the same commit myself, endorsing what Peff
did for the project, when I come back, by doing something like:

    $ git tag -s -m 'Git v2.7.1' v2.7.1 peff/v2.7.1^0
    $ git push $there v2.7.1

In fact, I think "git describe" uses the name recorded in the
closest tag, not the refname such a tag is found at, when giveing a
name to the commit.  E.g.

    $ git tag foo v2.7.0
    $ git tag -d v2.7.0
    $ git describe master
    warning: tag 'v2.7.0' is really 'foo' here
    v2.7.0-170-ge572fef