Re: [PATCH 4/6] fsck: check tag objects' headers

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 31, 2014, 22:46 UTC
Message-ID: <xmqqwq9o2s6l.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140829234641.GG24834@peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

> Hmm. But that is because "git tag" always makes one type of tag: one in
> which the "tag" field is the same as the refname in which we store it.
> So the name must be a valid refname there to meet the ref storage
> requirement, and therefore the tag name must, too.
>
> But is that something we necessarily need or want to enforce? Is it OK
> for me to have refs/tags/foo pointing to a tag object that is not
> related to "foo" (either semantically or syntactically)?
>
> I dunno. I cannot think of a reason you would want to do such a thing,
> but this seems like outlawing it because git does not generate it, not
> because it is necessarily a problematic thing to be doing.

Thanks for straightening me out.

If "git fsck" were a tool to validate that the objects and refs are in line with how "git-core" plumbing and Porcelain toolset uses the underlying Git data model, it makes sense to insist a tag has a name that is suitable for a refname, and the tag is pointed by a ref in "refs/tags/" followed by its name. The rules such a "git fsck" should implement would be stricter than what the underlying Git data model could represent and existing Git tools could handle (i.e. a commit with broken ident line may not be usable with "shortlog -e" and would be flagged as corrupt).

But tightening rules in that direction may risk hindering future progress in an unnecessary way. We may want to be a bit lenient when we see something _unusual_ but not necessarily _wrong_, and the line between them would be blurry in places, as Git is an evolving software. It is good to warn about an unsual ones, but we probably would not want to error on them.

This tightening may be too strict without a very good reason. For example, a tentative signed tag (e.g. "for-linus") often used in a pull request to have it recorded in the resulting merge by the integrator does not inherently need to be named at all; the ref is only necessary as a means to transfer the signature from the contributor to the integrator, and once merged, there is no need for the tag to have any name. When we try to improve the workflow to integrate authenticated work done on the side branch, we may come up with a way to do so _without_ having to actually have a tag name (i.e. the "tag" contributor creates for such a purpose may not be done by "git tag -s" when asking the result to be pulled but do something different, and it may be perfectly fine for such a tentative tag to lack the "tag " name line), but still allows us to record the same merge-tag in the resulting merge commit.

So...