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

Jeff King [off-list ref] writes:

quoted

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 [off-list ref] 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