Thanks for the thoughtful feedback, Junio!
On Thu 2019-03-21 10:31:59 +0900, Junio C Hamano wrote:
> 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.
It would be great if "git tag -v" would present a warning by default in
case of a tag name mismatch! I would not want to rule out making it
possible to return an error though.
I don't personally have any use case for doing such a tag rename -- you
mention two:
a) wanting to call tag "foo" that you found on remote "origin" by the
name of "origin/foo"
b) wanting to call "v2.20.0" by the name "g2.20.0"
And Ævar mentions a third:
c) mapping versioned tags (e.g. "v2.20.0") to tags with a date name
("2018-03-22")
I'm not sure how realistic or useful any of these patterns are. While
(a) seems the most plausible of the lot to me, none of them are things
i've ever seen in practice.
So i'd say that anyone in such a scenario is the outlier, and i wouldn't
want the existence of that edge case to make git less useful in the much
more common case.
Here's a revised proposal:
Consider a config setting named tag.verifyNameMatch, which can be true,
false, or some sort of sed expression name mangler.
- If set to true, it would do the thing that naive users probably
expect when they do "git tag -v foo" -- show a warning *and* return
an error if the tag message itself doesn't have "tag foo" in the
"header section" of the signed tag.
- If set to false, it wouldn't error out (though maybe it would still
show the warning).
- If set to a sed expression, it would feed the name being checked
through the sed expression and ensure that the resultant value was
present in the signed tag's "header section".
The mangler would work in a pretty straightforward way for (a)
(e.g. "s_origin/(.*)_\1_") and (b) (e.g. "s_v(.*)_g\1_").
i don't see how it would handle (c), but i think there are probably
better ways to handle (c) (if i'm understanding Ævar's scenario
correctly) than just trying to replay the upstream author's tags with
different names. For example, the curator of the repository could just
make their own signed tags, based on whatever policy they wanted. Or,
they could just ignore the warnings :P
As you can probably guess, i'd say that such a tag.verifyNameMatch
should default to true, but i'd also be ok if it started off defaulting
to false, to gather feedback about its impact, and eventually consider
transitioning it to true by default.
--dkg
