From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 01 Dec 2020 20:59:32 GMT
Subject: Re: [PATCH v2 10/10] mktag doc: update to explain why to use this
Message-ID: <xmqq8sahnsy3.fsf@gitster.c.googlers.com>
In-Reply-To: <20201126222257.5629-11-avarab@gmail.com>

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> 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