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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> This is a bit of an aside, but why do we have the "tag" line in the tag
> object in the first place?

http://thread.gmane.org/gmane.linux.kernel/297998/focus=1410

> It is part of the object contents, and therefore is part of the
> signature (which the refname is not). That's somewhat redundant with the
> tag message itself. E.g., the git v2.0.4 tag says:
>
>   object 32f56600bb6ac6fc57183e79d2c1515dfa56672f
>   type commit
>   tag v2.0.4
>   tagger Junio C Hamano <gitster@xxxxxxxxx> 1406755201 -0700
>
>   Git 2.0.4
>   -----BEGIN PGP SIGNATURE-----
>   ...

Yes, usually we write a moral equivalent in a human readable form as
the tag message, but the mapping "s/^v/Git /" between the tag name
and the message is purely by convention, and I suspect some old tags
I have may even have used "s/^v/Git v/" or "s/^v/git v/" or a
similar inconsistent mapping.

> The main advantage of the "tag" field is that it is machine-readable,
> and that your verification process can check that "git verify-tag
> v2.1.0" actually returns a tag that says "tag v2.1.0". But I do not
> think we do that verification at all. I wonder if that is something we
> should add support for.

Yes.  That essentially boils down to "refs/tags/$tag" must have "tag $tag"
line (the reverse may not have to be true if the hierarchy is
outside refs/tags/, though).
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]