On Tue, Jun 07, 2016 at 03:21:48PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > If you are suggesting that you can do the whole thing today by parsing > > the tag object yourself, then sure, I agree. I thought the point of the > > exercise was to make that less painful for the callers. > > Yes, and I somehow thought everybody agreed that --show-tag-name was > striking the balance at about the right level for ease-of-use and > simplicity? No, I think "--format" would be much better, unless you want to add a separate "--show-tagger-ident" when somebody wants to do a check between the tagger's ident and the key uid. But either way, I think the whole "do a rev-parse first" thing raises the question of what object identifiers "git tag" would accept. We would presumably expect: git tag --show-tag-name v1.0 to work. And I think in your world-view, so would: git tag --show-tag-name $(git rev-parse v1.0) How about: git tag --show-tag-name refs/tags/v1.0 And what about: git tag --show-tag-name refs/remotes/foo/v1.0 or even: git tag --show-tag-name foo/v1.0 when refs/remotes/foo/v1.0 exists? The rule right now is generally that "git tag" takes actual tag names. Plumbing like "verify-tag" takes arbitrary get_sha1() expressions, but you're expected to qualify or resolve your refnames before you get there, to avoid weird situations. This "tag --show-tag-name" seems to sit in the middle of plumbing and porcelain (for that matter, I am not sure that it should belong to git-tag at all, as it is really about scripting). -Peff -- 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