Junio C Hamano <gitster@xxxxxxxxx<mailto:gitster@xxxxxxxxx>> writes: >Tom Grennan <tom.grennan@xxxxxxxxxxxx<mailto:tom.grennan@xxxxxxxxxxxx>> writes: >> >>If the command argument is a non-tag object, scan and verify all tags to >>the given object; for example: >> >>john$ git tag -s -m "I approve" john-README master:README >>... >>john$ git tag -s -m "I recommend" john-HEAD HEAD >>... >>john$ git push <url> tag john-README >>john$ git push <url> tag john-HEAD >> >>jane$ git fetch --tags <url> >>jane$ git tag -s -m "I also approve" jane-README master:README >>... >>jane$ git push <url> tag jane-README >> >>jeff$ git fetch --tags <url> >>jeff$ git verify-tag master:README >>tag john-README: OK >>tag jane-README: OK >>jeff$ git verify-tag HEAD >>tag john-HEAD: OK >> >>Signed-off-by: Tom Grennan <tom.grennan@xxxxxxxxxxxx<mailto:tom.grennan@xxxxxxxxxxxx>> > >You did not describe what problem you are trying to solve, but the above >tells me that the design of this feature has a lot of room to be improved >to be useful for even a single trivial use scenario I can think of off the >top of my head. > >Let's say after tagging v1.7.10, for some reason (as I do not know what >problem you are trying to solve), I decided to ask my back-up maintainers, >let's call them Shawn and Jeff, to sign that tag. Shawn is expected to do >this: > > spearce$ git fetch tag v1.7.10 > spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce v1.7.10 > spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce > >Jeff will do the same, and I'll fetch v1.7.10-spearce and v1.7.10-peff >tags from them. > >It is natural for me to be able to ask "I want to verify all tags that >point at the object I asked to be signed, namely, v1.7.10" from this >feature. > >But > > gitster$ git verify-tag v1.7.10 > >would not be a way to do so, as that would check my signature in v1.7.10 >tag itself. > >It gets even worse. Suppose Jeff does this instead by mistake: > > peff$ git fetch v1.7.10 > peff$ git tag v1.7.10-peff v1.7.10 > peff$ git push http://example.com/peff/git tags/v1.7.10-peff > >Even if you added "git verify-tag --pointed v1.7.10" to disambiguate the >request to use the new feature, the result is unusable, as I would see: > > gitster$ git verify-tag --pointed v1.7.10 > v1.7.10-spearce: OK > v1.7.10-peff: OK > >v1.7.10-spearce and v1.7.10-peff both resolve to my v1.7.10, and they both >are signed by known key, but v1.7.10-peff is a lightweight tag that points >directly at my v1.7.10 and I would be seeing a signature of my own as "OK". Sorry for messing up this thread. I had remote access trouble with work. Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or blob) that you had tagged? spearce$ git fetch tag v1.7.10 spearce$ eval $(git verify-tag -v v1.7.10 | sed -n '1s/ /=/p') spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce $object spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce Or, spearce$ git fetch tag v1.7.10 spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce --pointed v1.7.10 spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce Then, gitster$ git verify-tag $object tag v1.7.10: OK tag v1.7.10-spearce: OK Or, gitster$ git verify-tag --pointed v1.7.10 tag v1.7.10: OK tag v1.7.10-spearce: OK I hadn't thought of tagging a tag. As you indicate, this would be tricky to disambiguate. So, I intended this to verify all tags of the non-tag object that one asked to be signed; no sign, no record. BTW, it may also be convenient to use auto-generated tag names for the secondary sign-offs, perhaps using the tag SHA as it's refs/tags/SHA. spearce$ git tag -s -m "This is Gitster's v1.7.10" -- --pointed v1.7.10 peff$ git tag -s -m "This is Gitster's v1.7.10" -- --pointed v1.7.10 gitster$ git verify-tag --pointed v1.7.10 tag v1.7.10: OK tag XXX....XXX: OK tag YYY....YYY: OK `git tag -l` could then ignore refs/tags/SHA with content SHA. -- TomG -- 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