Thanks for this great explanation of how tags work. Hopefully some or
all of this can get incorporated into the git's user's manual.
Adding the paragraph to the git-tag as you did in your patch is a
good start, but having the entire explanation of how things work in
the user's manual would be a really good thing, IMHO.
This brings up another question which I've been looking for, but for
which I haven't found a good answer in the git documentation. A
google search shows a suggestion by hpa (and a brief discussion from
sct) about how to handle conflicting tags back in 2005, but as far as
I can tell it didn't go anywhere.
Anyway, the questions that don't appear to be addressed in the git
documentations are:
1) Suppose I do a "git tag" of a release, and then realize that I
messed up, and I need to do some additional release work (i.e.,
editing a debian changelog file, etc.) before really doing another
release, what do I do to tag a later revision as the "real" version
v1.2?
2) Suppose I have v2.6.20 pointing to a particular revision, which was
obtained from pulling from Linus's tree, and I pull from some other
tree, say the wireless tree, and the maintainer there either
accidentally or maliciously has the tag v2.6.20 pointing to some other
revision. What happens in that case? Does the answer change if the
tag is a signed vs. unsigned tag?
3) The git-tag man page talks about GPG signing tags, but it doesn't
talk about how a GPG-signed tag is validated. Does this happen
manually or automatically? If it happens manually, how should a tag
be verified? If the answer is using git-verify-tag, then there should
probably be better references in the documentation to git-verify-tag.
It might also be a very good idea to have a config option which
automatically verifies signed tags.
4) Is there a good/easy way to show whether a tag is a signed
vs. unsigned tag? Short of using "git cat-file -t <tag>", there
doesn't seem to be, and being forced to use a low-level git command to
get that kind of information seems.... unsatisfactory.
Thanks,
- Ted
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
