{"thread":{"id":"56675","subject":"[PATCH 1/1] signature-format.txt: add space to fix gpgsig continuation line","startedAt":"2021-10-09T16:41:28Z","lastAt":"2021-10-15T23:29:43Z","messageCount":11,"participants":["Rob Browning","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"438412","messageId":"20211009163338.2175170-1-rlb@defaultvalue.org","threadId":"56675","inReplyTo":null,"subject":"[PATCH 1/1] signature-format.txt: add space to fix gpgsig continuation line","fromName":"Rob Browning","fromEmail":"rlb@defaultvalue.org","sentAt":"2021-10-09T16:33:38Z","receivedAt":"2021-10-09T16:41:28Z","isPatch":true,"sender":{"key":"rlb@defaultvalue.org","avatar":null},"body":"Add a space to the blank line after the version header in the example\ngpgsig commit header.\n\nSigned-off-by: Rob Browning \n---\n\n While investigating this (while parsing commit objects) I also\n noticed a commit in a repo that had a blank continuation line (\" \\n\")\n after the \"END PGP SIGNATURE\" line.\n\n Presuming that's valid, I suppose we could consider detailing any\n additional specifications, i.e. what kind of trailing content a\n parser should expect/ignore, etc.\n\n Documentation/technical/signature-format.txt | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/technical/signature-format.txt b/Documentation/technical/signature-format.txt\nindex 2c9406a56a..6acc0b1247 100644\n--- a/Documentation/technical/signature-format.txt\n+++ b/Documentation/technical/signature-format.txt\n@@ -78,7 +78,7 @@ author A U Thor 1465981137 +0000\n committer C O Mitter 1465981137 +0000\n gpgsig -----BEGIN PGP SIGNATURE-----\n Version: GnuPG v1\n-\n+ \n iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/\n HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7\n DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA\n-- \n2.30.2\n\n"},{"id":"438479","messageId":"YWRpPw4eTwTmgVvC@coredump.intra.peff.net","threadId":"56675","inReplyTo":"20211009163338.2175170-1-rlb@defaultvalue.org","subject":"Re: [PATCH 1/1] signature-format.txt: add space to fix gpgsig continuation line","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-10-11T16:41:35Z","receivedAt":"2021-10-11T16:41:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 09, 2021 at 11:33:38AM -0500, Rob Browning wrote:\n\n> Add a space to the blank line after the version header in the example\n> gpgsig commit header.\n\nThanks, this is a good catch. The space is important for the header\ncontinuation.\n\n> diff --git a/Documentation/technical/signature-format.txt b/Documentation/technical/signature-format.txt\n> index 2c9406a56a..6acc0b1247 100644\n> --- a/Documentation/technical/signature-format.txt\n> +++ b/Documentation/technical/signature-format.txt\n> @@ -78,7 +78,7 @@ author A U Thor 1465981137 +0000\n> committer C O Mitter 1465981137 +0000\n> gpgsig -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v1\n> -\n> + \n> iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/\n> HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7\n> DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA\n\nThe patch is quite subtle to read, of course. :) But more importantly,\nit is subtle for somebody reading the documentation to notice. Perhaps\nit's worth calling it out explicitly? E.g., squashing in something like:\n\ndiff --git a/Documentation/technical/signature-format.txt b/Documentation/technical/signature-format.txt\nindex 6acc0b1247..f418431050 100644\n--- a/Documentation/technical/signature-format.txt\n+++ b/Documentation/technical/signature-format.txt\n@@ -68,7 +68,9 @@ signed tag message body\n - created by: `git commit -S`\n - payload: commit object\n - embedding: header entry `gpgsig`\n- (content is preceded by a space)\n+ (content is preceded by a space; note that this includes the\n+ \"empty\" line between the GnuPG header and signature, which\n+ consists of a single space).\n - example: commit with subject `signed commit`\n \n ----\n\n> While investigating this (while parsing commit objects) I also\n> noticed a commit in a repo that had a blank continuation line (\" \\n\")\n> after the \"END PGP SIGNATURE\" line.\n> \n> Presuming that's valid, I suppose we could consider detailing any\n> additional specifications, i.e. what kind of trailing content a\n> parser should expect/ignore, etc.\n\nIt is valid. It looks like GitHub's signed-merges may do this. From our\nperspective, we are not really defining what is valid content or not. We\ntake everything in the gpgsig header (including multiple lines connected\nby space-continuation), and feed it to gpg. So if gpg is happy with it,\nwe are happy with it.\n\nThinking with a security hat on, it's possible this could lead to\nconfusion (say, if I include multiple signatures but some tools check\none and some the other). But I'd be hesitant to start adding\nrestrictions without even a plausible attack scenario.\n\n-Peff\n"},{"id":"438488","messageId":"xmqq4k9ncopr.fsf@gitster.g","threadId":"56675","inReplyTo":"YWRpPw4eTwTmgVvC@coredump.intra.peff.net","subject":"Re: [PATCH 1/1] signature-format.txt: add space to fix gpgsig continuation line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-11T20:04:48Z","receivedAt":"2021-10-11T20:04:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sat, Oct 09, 2021 at 11:33:38AM -0500, Rob Browning wrote:\n>\n>> Add a space to the blank line after the version header in the example\n>> gpgsig commit header.\n>\n> Thanks, this is a good catch. The space is important for the header\n> continuation.\n>\n>> diff --git a/Documentation/technical/signature-format.txt b/Documentation/technical/signature-format.txt\n>> index 2c9406a56a..6acc0b1247 100644\n>> --- a/Documentation/technical/signature-format.txt\n>> +++ b/Documentation/technical/signature-format.txt\n>> @@ -78,7 +78,7 @@ author A U Thor 1465981137 +0000\n>> committer C O Mitter 1465981137 +0000\n>> gpgsig -----BEGIN PGP SIGNATURE-----\n>> Version: GnuPG v1\n>> -\n>> + \n>> iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/\n>> HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7\n>> DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA\n>\n> The patch is quite subtle to read, of course. :) But more importantly,\n> it is subtle for somebody reading the documentation to notice. Perhaps\n> it's worth calling it out explicitly? E.g., squashing in something like:\n> ...\n> - (content is preceded by a space)\n> + (content is preceded by a space; note that this includes the\n> + \"empty\" line between the GnuPG header and signature, which\n> + consists of a single space).\n> - example: commit with subject `signed commit`\n\nTo those who are reading on paper or on terminal, the difference\nwill not be even seen. It only can be _found_ if you are in an\neditor or a pager and explicitly look for a trailing whitespace (or\ntold your tool to highlight such for you).\n\nI wonder if we can have some typesetting convention for this part of\nthe documentation. Perhaps something like\n\n In the following example, the end of line that ends with a\n whitespace letter is highlighted with a \"$\" sign; if you are\n trying to recreate these example by hand, do not cut and paste\n them---they are there primarily to highlight extra whitespace at\n the end of some lines.\n\nbefore a displayed material like this:\n\n committer C O Mitter 1465981137 +0000\n gpgsig -----BEGIN PGP SIGNATURE-----\n Version: GnuPG v1\n $\n iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/\n HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7\n DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA\n\nperhaps?\n\nI am reasonably sure that running \"git am\" on Rob's patch will by\ndefault end up as a no-op patch, because auto-correcting whitespace\nbreakage is the default setting I use, and a change like the one\nsuggested above would help avoid such a problem, too.\n\nThanks.\n\n"},{"id":"438513","messageId":"YWTuAOjqK6fy9ZRT@coredump.intra.peff.net","threadId":"56675","inReplyTo":"xmqq4k9ncopr.fsf@gitster.g","subject":"Re: [PATCH 1/1] signature-format.txt: add space to fix gpgsig continuation line","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-10-12T02:08:00Z","receivedAt":"2021-10-12T02:08:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 11, 2021 at 01:04:48PM -0700, Junio C Hamano wrote:\n\n> > The patch is quite subtle to read, of course. :) But more importantly,\n> > it is subtle for somebody reading the documentation to notice. Perhaps\n> > it's worth calling it out explicitly? E.g., squashing in something like:\n> > ...\n> > - (content is preceded by a space)\n> > + (content is preceded by a space; note that this includes the\n> > + \"empty\" line between the GnuPG header and signature, which\n> > + consists of a single space).\n> > - example: commit with subject `signed commit`\n> \n> To those who are reading on paper or on terminal, the difference\n> will not be even seen. It only can be _found_ if you are in an\n> editor or a pager and explicitly look for a trailing whitespace (or\n> told your tool to highlight such for you).\n\nYeah, I was hoping that calling it out explicitly would help to serve\nthat purpose, even if they can't see it. But it's still pretty subtle.\n\nI did consider annotating it more directly in the example, but I was\nworried it would end up being syntactically confusing, because we don't\nhave a well-known convention for marking \"end of line\". But the example\nyou showed:\n\n> I wonder if we can have some typesetting convention for this part of\n> the documentation. Perhaps something like\n> \n> In the following example, the end of line that ends with a\n> whitespace letter is highlighted with a \"$\" sign; if you are\n> trying to recreate these example by hand, do not cut and paste\n> them---they are there primarily to highlight extra whitespace at\n> the end of some lines.\n> \n> before a displayed material like this:\n> \n> committer C O Mitter 1465981137 +0000\n> gpgsig -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v1\n> $\n> iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/\n> HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7\n> DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA\n> \n> perhaps?\n\n...coupled with the explanation you gave is not too bad. I had thought\nto maybe do something like:\n\n gpgsig -----BEGIN PGP SIGNATURE-----\n _Version: GnuPG v1\n _\n _iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/\n _HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7\n _DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA\n\nbut that is pretty ugly. I like yours much better.\n\n-Peff\n"},{"id":"438569","messageId":"xmqqzgre5glb.fsf@gitster.g","threadId":"56675","inReplyTo":"YWTuAOjqK6fy9ZRT@coredump.intra.peff.net","subject":"Re: [PATCH 1/1] signature-format.txt: add space to fix gpgsig continuation line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-12T16:54:24Z","receivedAt":"2021-10-12T16:54:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> In the following example, the end of line that ends with a\n>> whitespace letter is highlighted with a \"$\" sign; if you are\n>> trying to recreate these example by hand, do not cut and paste\n>> them---they are there primarily to highlight extra whitespace at\n>> the end of some lines.\n>> \n>> before a displayed material like this:\n>> \n>> committer C O Mitter 1465981137 +0000\n>> gpgsig -----BEGIN PGP SIGNATURE-----\n>> Version: GnuPG v1\n>> $\n>> iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/\n>> HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7\n>> DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA\n>> \n>> perhaps?\n>\n> ...coupled with the explanation you gave is not too bad. I had thought\n> to maybe do something like:\n>\n> gpgsig -----BEGIN PGP SIGNATURE-----\n> _Version: GnuPG v1\n> _\n> _iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/\n> _HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7\n> _DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA\n>\n> but that is pretty ugly. I like yours much better.\n\nYes, I did consider a replacement for SP and rejected for the same\nreason as you did. We could use the same \"we only show the 'here is\na SP' sign when the presence of the SP cannot be seen\" convention to\nmake it less distracting, but I think '$' taken from \"cat -e\"\nprobably is easier to see and understand for those who are the\ntarget audience of anything in Documentation/technical/ hierarchy.\n\nThanks.\n\n\n\n"},{"id":"438625","messageId":"xmqqtuhlisqe.fsf_-_@gitster.g","threadId":"56675","inReplyTo":"xmqqzgre5glb.fsf@gitster.g","subject":"[PATCH] signature-format.txt: explain and illustrate multi-line headers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-13T02:06:01Z","receivedAt":"2021-10-13T02:06:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A signature attached to a signed commit, and the contents of the\ncommit that merged a signed tag, are both recorded as a value of an\nobject header field as a multi-line value, and are subject to the\nformatting convention for multi-line values in the headers, with a\nleading SP signaling that the rest of the line is a continuation of\nthe previous line. Most notably, an empty line in such a multi-line\nvalue would result in a line with a sole SP on it.\n\nExamples in the signature-format technical documentation include a\nfew of these cases but we did not show these otherwise invisible SPs\nin the example. These trailing spaces cannot be seen on display or\non paper, and forces the readers to look for them in their editors\nor pagers, even if we added them to the document.\n\nExtend the overview section to explain the multi-line value\nformatting and highlight these otherwise invisible SPs by inventing\nthe \"a dollar-sign at the end of line that appears after SP merely\nsignals that there is a SP there, and the dollar-sign itself does\nnot appear in the real file\" notation, inspired by \"cat -e\" output,\nto help readers to learn exactly where such \"a single SP that is\noriginally an empty line\" appears in the examples.\n\nReported-by: Rob Browning \nSigned-off-by: Junio C Hamano \n---\n\n It turns out that the document has another block of text that\n needed the same treatment, so here is an attempt to follow\n through with the \"$\"-notation approach.\n\n Documentation/technical/signature-format.txt | 25 ++++++++++++++++----\n 1 file changed, 21 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/technical/signature-format.txt b/Documentation/technical/signature-format.txt\nindex 2c9406a56a..45448fba24 100644\n--- a/Documentation/technical/signature-format.txt\n+++ b/Documentation/technical/signature-format.txt\n@@ -13,9 +13,25 @@ Signatures always begin with `-----BEGIN PGP SIGNATURE-----`\n and end with `-----END PGP SIGNATURE-----`, unless gpg is told to\n produce RFC1991 signatures which use `MESSAGE` instead of `SIGNATURE`.\n \n+Signatures sometimes appear as a part of the normal payload\n+(e.g. a signed tag has the signature block appended after the payload\n+that the signature applies to), and sometimes appear in the value of\n+an object header (e.g. a merge commit that merged a signed tag would\n+have the entire tag contents on its \"mergetag\" header). In the case\n+of the latter, the usual multi-line formatting rule for object\n+headers applies. I.e. the second and subsequent lines are prefixed\n+with a SP to signal that the line is continued from the previous\n+line.\n+\n+This is even true for an originally empty line. In the following\n+examples, the end of line that ends with a whitespace letter is\n+highlighted with a `$` sign; if you are trying to recreate these\n+example by hand, do not cut and paste them---they are there\n+primarily to highlight extra whitespace at the end of some lines.\n+\n The signed payload and the way the signature is embedded depends\n on the type of the object resp. transaction.\n \n == Tag signatures\n \n - created by: `git tag -s`\n@@ -78,7 +95,7 @@ author A U Thor 1465981137 +0000\n committer C O Mitter 1465981137 +0000\n gpgsig -----BEGIN PGP SIGNATURE-----\n Version: GnuPG v1\n-\n+ $\n iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/\n HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7\n DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA\n@@ -128,13 +145,13 @@ mergetag object 04b871796dc0420f8e7561a895b52484b701d51a\n type commit\n tag signedtag\n tagger C O Mitter 1465981006 +0000\n-\n+ $\n signed tag\n-\n+ $\n signed tag message body\n -----BEGIN PGP SIGNATURE-----\n Version: GnuPG v1\n-\n+ $\n iQEcBAABAgAGBQJXYRhOAAoJEGEJLoW3InGJklkIAIcnhL7RwEb/+QeX9enkXhxn\n rxfdqrvWd1K80sl2TOt8Bg/NYwrUBw/RWJ+sg/hhHp4WtvE1HDGHlkEz3y11Lkuh\n 8tSxS3qKTxXUGozyPGuE90sJfExhZlW4knIQ1wt/yWqM+33E9pN4hzPqLwyrdods\n-- \n2.33.1-816-gd427230396\n\n"},{"id":"438748","messageId":"87zgrcgpez.fsf@trouble.defaultvalue.org","threadId":"56675","inReplyTo":"xmqqtuhlisqe.fsf_-_@gitster.g","subject":"Re: [PATCH] signature-format.txt: explain and illustrate multi-line headers","fromName":"Rob Browning","fromEmail":"rlb@defaultvalue.org","sentAt":"2021-10-14T05:12:52Z","receivedAt":"2021-10-14T05:12:54Z","isPatch":true,"sender":{"key":"rlb@defaultvalue.org","avatar":null},"body":"Junio C Hamano writes:\n\n> A signature attached to a signed commit, and the contents of the\n> commit that merged a signed tag, are both recorded as a value of an\n> object header field as a multi-line value, and are subject to the\n> formatting convention for multi-line values in the headers, with a\n> leading SP signaling that the rest of the line is a continuation of\n> the previous line. Most notably, an empty line in such a multi-line\n> value would result in a line with a sole SP on it.\n\nOne question I had was whether git's requirement was strictly a space,\nor if it was following the rfc-822 convention where (if I remember\ncorrectly) a tab is equivalent, i.e. the LWSP production in the grammar.\n\nhttps://datatracker.ietf.org/doc/html/rfc822#section-3.2\n\nThanks\n-- \nRob Browning\nrlb @defaultvalue.org and @debian.org\nGPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A\nGPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4\n"},{"id":"438767","messageId":"xmqq5ytzcyr6.fsf@gitster.g","threadId":"56675","inReplyTo":"87zgrcgpez.fsf@trouble.defaultvalue.org","subject":"Re: [PATCH] signature-format.txt: explain and illustrate multi-line headers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-14T17:17:01Z","receivedAt":"2021-10-14T17:17:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rob Browning writes:\n\n> One question I had was whether git's requirement was strictly a space,\n> or if it was following the rfc-822 convention where (if I remember\n> correctly) a tab is equivalent, i.e. the LWSP production in the grammar.\n\nWe use a single SP when writing and we accept a single SP when\nreading. See commit.c::add_extra_header() for the writing side, and\ncommit.c::read_commit_extra_header_lines() for the reading side.\n\nUnlike in RFC-822 style e-mail headers, \n\n * keywords in our object headers are not followed by a colon;\n\n * the value carried on our object header is not a \"logically a\n single line of characters\". \n\n * our headers do not go through their \"unfolding\" (i.e. removal of\n CRLF eol markers to form a single long line, while preserving the\n WSP that immediately followed the CRLF). We instead remove the\n SP that signalled the line as a continuation of the previous line\n to keep the original line structure.\n\nWith so little similarity, there is no reason for us to mimick their\n\"folding\" rule.\n\nWe limit to the SP and not LWP for another reason. Because the\nexact byte sequence in the object (including the header part of\n\"commit\" and \"tag\" objects) determines the name of the object, it\navoids ambiguity to make sure we do not allow unnecessary\n\"flexibility\" in the way the same thing can be expressed. If the\nsame signature is attached to a pair of otherwise identical commits\nin their headers, one with SP signaling continued lines, the other\nusing HT (or random permutations of choice between SP/HT---making\n2^N variants for a N line signature block), we would needlessly\ncreate many variants of the \"same\" commit, which is not ideal.\n"},{"id":"438804","messageId":"87v91zgjr9.fsf@trouble.defaultvalue.org","threadId":"56675","inReplyTo":"xmqq5ytzcyr6.fsf@gitster.g","subject":"Re: [PATCH] signature-format.txt: explain and illustrate multi-line headers","fromName":"Rob Browning","fromEmail":"rlb@defaultvalue.org","sentAt":"2021-10-15T01:27:22Z","receivedAt":"2021-10-15T01:28:02Z","isPatch":true,"sender":{"key":"rlb@defaultvalue.org","avatar":null},"body":"Junio C Hamano writes:\n\n> With so little similarity, there is no reason for us to mimick their\n> \"folding\" rule.\n\nAgreed. I'd just lazily guessed it might be 822 (was also thinking of\nDebian package headers), but certainly shouldn't have glossed over the\nmissing colon (for example) -- might be worth making sure the rules\ndescribed are covered in the technical docs, if they're not already, and\nthen perhaps refer to them in the section we're adjusting.\n\n> We limit to the SP and not LWP for another reason. Because the\n> exact byte sequence in the object (including the header part of\n> \"commit\" and \"tag\" objects) determines the name of the object\n\nAhh, right, of course.\n\n> we would needlessly create many variants of the \"same\" commit, which\n> is not ideal.\n\nIndeed.\n\nThanks\n-- \nRob Browning\nrlb @defaultvalue.org and @debian.org\nGPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A\nGPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4\n"},{"id":"438856","messageId":"xmqqa6ja9t54.fsf@gitster.g","threadId":"56675","inReplyTo":"87v91zgjr9.fsf@trouble.defaultvalue.org","subject":"Re: [PATCH] signature-format.txt: explain and illustrate multi-line headers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-15T15:58:47Z","receivedAt":"2021-10-15T15:58:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rob Browning writes:\n\n> Agreed. I'd just lazily guessed it might be 822 (was also thinking of\n> ...\n> Ahh, right, of course.\n> ...\n> Indeed.\n>\n> Thanks\n\nSo, back to the original discussion; would the replacement\ndocumentation update be satisfactory?\n\n"},{"id":"438916","messageId":"87sfx1hnp4.fsf@trouble.defaultvalue.org","threadId":"56675","inReplyTo":"xmqqa6ja9t54.fsf@gitster.g","subject":"Re: [PATCH] signature-format.txt: explain and illustrate multi-line headers","fromName":"Rob Browning","fromEmail":"rlb@defaultvalue.org","sentAt":"2021-10-15T23:29:11Z","receivedAt":"2021-10-15T23:29:43Z","isPatch":true,"sender":{"key":"rlb@defaultvalue.org","avatar":null},"body":"Junio C Hamano writes:\n\n> Rob Browning writes:\n>\n>> Agreed. I'd just lazily guessed it might be 822 (was also thinking of\n>> ...\n>> Ahh, right, of course.\n>> ...\n>> Indeed.\n>>\n>> Thanks\n>\n> So, back to the original discussion; would the replacement\n> documentation update be satisfactory?\n\nCertainly, and thanks.\n\n-- \nRob Browning\nrlb @defaultvalue.org and @debian.org\nGPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A\nGPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4\n"}]}