Jeff King <peff@xxxxxxxx> 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@xxxxxxxxx> 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
--
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