Re: [PATCH] signature-format.txt: explain and illustrate multi-line headers

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 14, 2021, 17:17 UTC
Message-ID: <xmqq5ytzcyr6.fsf@gitster.g>
In-Reply-To: <87zgrcgpez.fsf@trouble.defaultvalue.org>

Rob Browning <rlb@defaultvalue.org> writes:

> One question I had was whether git's requirement was strictly a space,
> or if it was following the rfc-822 convention where (if I remember
> correctly) a tab is equivalent, i.e. the LWSP production in the grammar.

We use a single SP when writing and we accept a single SP when reading. See commit.c::add_extra_header() for the writing side, and commit.c::read_commit_extra_header_lines() for the reading side.

Unlike in RFC-822 style e-mail headers,

 * keywords in our object headers are not followed by a colon;

 * the value carried on our object header is not a "logically a
   single line of characters".

 * our headers do not go through their "unfolding" (i.e. removal of
   CRLF eol markers to form a single long line, while preserving the
   WSP that immediately followed the CRLF).  We instead remove the
   SP that signalled the line as a continuation of the previous line
   to keep the original line structure.

With so little similarity, there is no reason for us to mimick their "folding" rule.

We limit to the SP and not LWP for another reason. Because the exact byte sequence in the object (including the header part of "commit" and "tag" objects) determines the name of the object, it avoids ambiguity to make sure we do not allow unnecessary "flexibility" in the way the same thing can be expressed. If the same signature is attached to a pair of otherwise identical commits in their headers, one with SP signaling continued lines, the other using HT (or random permutations of choice between SP/HT---making 2^N variants for a N line signature block), we would needlessly create many variants of the "same" commit, which is not ideal.