Re: [PATCH 00/15] git-note: A mechanisim for providing free-form after-the-fact annotations on commits

From: Junio C Hamano <junkio@cox.net>
Date: May 28, 2007, 20:45 UTC
Message-ID: <7vps4kbrtb.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200705281254.23297.johan@herland.net>

Johan Herland <johan@herland.net> writes:

Show 10 quoted lines

> 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).