On Thu, Mar 21 2019, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> * "git tag -v $(git rev-parse v1.0.0)" should work, but the command > > Sorry, forget about this part of my message. I completely forgot the > discussion we had a few years ago: > > https://public-inbox.org/git/CAPc5daV9ZvHqFtdzr565vp6Mv7O66ySr-p5Vi8o6bd6=GyVELg@xxxxxxxxxxxxxx/ > > In short, "git tag -v TAGNAME" does not take an arbitrary object > name, TAGNAME does not go through the usual ref dwimming rules > (i.e. checking for .git/%s, .git/tag/%s, .git/heads/%s, ... to find > one) but only looks at refs/tags/TAGNAME alone. So we always have > the refname it came from when inspecting tag contents that tells > what tagname the tag has. > > The other point still stands; there are legitimate reasons people > would want to have a tag with v1.0.0 tagname in somewhere that is > not refs/tags/v1.0.0 and an extra validation must need to make sure > it won't error out, even though warning is probably acceptable. One such example, which I don't know is actually used, but we might be careful to break is: * Someone (e.g. Junio) is producing signed tags of a project like git.git * Someone else has a git repo where only upstream (signed by Junio) releases are allowed, but they decide *which* release. * Some system auto-deploys whatever the latest sorted tag in that repo is, after verifying that Junio tagged them. Thus e.g. v2.21.0 might be pushed as refs/tags/2018-03-21, and if it doesn't work out a new refs/tags/2018-03-22 might be tagged tomorrow using the v2.20.0 tag.
