Jeff King <p...@peff.net> writes: > This is a bit of an aside, but why do we have the "tag" line in the tag > object in the first place?
http://thread.gmane.org/gmane.linux.kernel/297998/focus=1410 > It is part of the object contents, and therefore is part of the > signature (which the refname is not). That's somewhat redundant with the > tag message itself. E.g., the git v2.0.4 tag says: > > object 32f56600bb6ac6fc57183e79d2c1515dfa56672f > type commit > tag v2.0.4 > tagger Junio C Hamano <gits...@pobox.com> 1406755201 -0700 > > Git 2.0.4 > -----BEGIN PGP SIGNATURE----- > ... Yes, usually we write a moral equivalent in a human readable form as the tag message, but the mapping "s/^v/Git /" between the tag name and the message is purely by convention, and I suspect some old tags I have may even have used "s/^v/Git v/" or "s/^v/git v/" or a similar inconsistent mapping. > The main advantage of the "tag" field is that it is machine-readable, > and that your verification process can check that "git verify-tag > v2.1.0" actually returns a tag that says "tag v2.1.0". But I do not > think we do that verification at all. I wonder if that is something we > should add support for. Yes. That essentially boils down to "refs/tags/$tag" must have "tag $tag" line (the reverse may not have to be true if the hierarchy is outside refs/tags/, though). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
