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

Rob Browning [off-list ref] 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.