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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html