Johan Herland <johan@xxxxxxxxxxx> writes: > And while we're on the subject of changing the tag object, I'd like for > the "tag" header (the one holding the tag name) to become optional. > When doing my ref <-> name trick above, I conveniently forgot this little > bugger. Basically the only reason for this one to exist is to include the > name of the tag in the data passed to gpg for signing. This is of course > necesssary in order to make renaming a signed tag impossible. (Allowing > renaming would make it possible to replace it with a malicious tag with > the original name.) Therefore the "tag" header must be mandatory for > signed tags. But for all other tags (including notes) this header is > pretty much useless. This brings up an interesting point, by the way. Currently when you say $ git show v2.6.22 we "dwim_ref" v2.6.22. That is, we try to see if ".git/v2.6.22" is there (it isn't), check ".git/refs/v2.6.22" (no, again), then happily find that ".git/refs/tags/v2.6.22" is there and use it. During this process we _never_ check if the tag object pointed at by the ref v2.6.22 has tagname v2.6.22 at all. I do not think it is a problem at all that we do not use "tag" name during the look-up process. However it would be a good idea to add logic to fsck to warn upon inconsistencis (perhaps by mistake) between refname and tag's true name. The check would say something like: If an annotated (signed or unsigned) tag has a "tag" line to give it the official $name, and if it is pointed at by a ref, the refname must end with "/$name". Otherwise we warn. Trivially, the above rule says that having v2.6.22 tag under refs/tags/v2.6.20 is a mistake we would want to be warned upon. The "/$name" part is to support merging a separate project into another project after the fact better. Shawn graciously names his tags in git-gui project "gitgui-0.7.1", to avoid tag name collisions with "v1.5.0" style tag names in git.git project, but we could have stored his v0.7.1 tag as refs/tags/gitgui/v0.7.1 to differenciate the tag namespace (this needs an update to the "tag following" code in git-fetch with a new configuration). - 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
