Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > +Reads a tag contents on standard input and creates a tag object. The > +output is the new tag's <object> identifier. > + > +This command accepts a subset of what linkgit:git-hash-object[1] would > +accept with `-t tag --stdin`. I.e. both of these work: > + > + git mktag <my-tag > + git hash-object -t tag --stdin <my-tag It's misleading to say "both of these work", I am afraid. If the former works, the latter would. That is what "accepts a subset" means, no? > +The difference between the two is that mktag does the equivalent of a > +linkgit:git-fsck(1) check on its input, and furthermore disallows some > +thing linkgit:git-hash-object[1] would pass, e.g. extra headers in the > +object before the message. Good description. > @@ -34,6 +44,17 @@ exists, is separated by a blank line from the header. The > message part may contain a signature that Git itself doesn't > care about, but that can be verified with gpg. > > +HISTORY > +------- > + > +In versions of Git before v2.30.0 the "mktag" command's validation Hardcoding v2.30.0 here feels problematic. If the series cooks in 'next' while 2.30 gets released, it has to be kicked out of 'next' to update this line before it gets allowed in 'next'. > +logic was subtly different than that of linkgit:git-fsck[1]. It is now > +a strict superset of linkgit:git-fsck[1]'s validation logic. It may be a better direction to go to drop this section. Also, I somehow have a feeling that we'd rather want to loosen the "no other headers allowed" in the longer run to be consistent with what "fsck" does. I also wonder if we want to teach "commit-tree" to also run fsck check like this new version of mktag does. It is outside the scope of this "mktag" series, of course. Thanks. > +SEE ALSO > +-------- > +linkgit:git-hash-object[1], > + > GIT > --- > Part of the linkgit:git[1] suite
