{"thread":{"id":"64221","subject":"[PATCH] doc: patch-id: fix accidental literal blocks","startedAt":"2025-09-28T14:03:30Z","lastAt":"2025-09-29T22:18:08Z","messageCount":7,"participants":["kristofferhaugsbakk@fastmail.com","Kristoffer Haugsbakk","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"527508","messageId":"0520e8f9caf.1759067095.git.code@khaugsbakk.name","threadId":"64221","inReplyTo":null,"subject":"[PATCH] doc: patch-id: fix accidental literal blocks","fromName":"","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-09-28T14:03:08Z","receivedAt":"2025-09-28T14:03:30Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"From: Kristoffer Haugsbakk \n\nThe options here are apparently written with the assumption that you\ncan continue a block like e.g. a description list by maintaining the\nsame indentation level. This is not the the case; you need to use list\ncontinuation (+) for the elements following the first paragraph if you\nwant to be guaranteed a predictable output\n\nThis is kind of subtle since only the last paragraph of each option gets\nrendered in an unintended way, namely as literal blocks. This is easier\nto see in the HTML output since the man page output just has a slightly\nlarger indentation on these paragraphs.\n\nLet’s use list continuation throughout, collapse the indentation in\nfront of all paragraphs except the first one, and wrap the unordered\nlist in an open block (`--`).\n\nSigned-off-by: Kristoffer Haugsbakk \n---\n Documentation/git-patch-id.adoc | 43 ++++++++++++++++++---------------\n 1 file changed, 23 insertions(+), 20 deletions(-)\n\ndiff --git a/Documentation/git-patch-id.adoc b/Documentation/git-patch-id.adoc\nindex 1d15fa45d51..45da0f27acd 100644\n--- a/Documentation/git-patch-id.adoc\n+++ b/Documentation/git-patch-id.adoc\n@@ -33,27 +33,30 @@ OPTIONS\n --verbatim::\n \tCalculate the patch-id of the input as it is given, do not strip\n \tany whitespace.\n-\n-\tThis is the default if patchid.verbatim is true.\n++\n+This is the default if patchid.verbatim is true.\n \n --stable::\n \tUse a \"stable\" sum of hashes as the patch ID. With this option:\n-\t - Reordering file diffs that make up a patch does not affect the ID.\n-\t In particular, two patches produced by comparing the same two trees\n-\t with two different settings for \"-O\" result in the same\n-\t patch ID signature, thereby allowing the computed result to be used\n-\t as a key to index some meta-information about the change between\n-\t the two trees;\n-\n-\t - Result is different from the value produced by git 1.9 and older\n-\t or produced when an \"unstable\" hash (see --unstable below) is\n-\t configured - even when used on a diff output taken without any use\n-\t of \"-O\", thereby making existing databases storing such\n-\t \"unstable\" or historical patch-ids unusable.\n-\n-\t - All whitespace within the patch is ignored and does not affect the id.\n-\n-\tThis is the default if patchid.stable is set to true.\n++\n+--\n+- Reordering file diffs that make up a patch does not affect the ID.\n+ In particular, two patches produced by comparing the same two trees\n+ with two different settings for \"-O\" result in the same\n+ patch ID signature, thereby allowing the computed result to be used\n+ as a key to index some meta-information about the change between\n+ the two trees;\n+\n+- Result is different from the value produced by git 1.9 and older\n+ or produced when an \"unstable\" hash (see --unstable below) is\n+ configured - even when used on a diff output taken without any use\n+ of \"-O\", thereby making existing databases storing such\n+ \"unstable\" or historical patch-ids unusable.\n+\n+- All whitespace within the patch is ignored and does not affect the id.\n+--\n++\n+This is the default if patchid.stable is set to true.\n \n --unstable::\n \tUse an \"unstable\" hash as the patch ID. With this option,\n@@ -61,8 +64,8 @@ OPTIONS\n \tby git 1.9 and older and whitespace is ignored. Users with pre-existing\n \tdatabases storing patch-ids produced by git 1.9 and older (who do not deal\n \twith reordered patches) may want to use this option.\n-\n-\tThis is the default.\n++\n+This is the default.\n \n GIT\n ---\n\nbase-commit: c44beea485f0f2feaf460e2ac87fdd5608d63cf0\n-- \n2.51.0.327.gddebdc8c038\n\n"},{"id":"527513","messageId":"a87b3e69-20a1-46bd-8d22-ed78145cc59c@app.fastmail.com","threadId":"64221","inReplyTo":"0520e8f9caf.1759067095.git.code@khaugsbakk.name","subject":"Re: [PATCH] doc: patch-id: fix accidental literal blocks","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-09-28T15:45:54Z","receivedAt":"2025-09-28T15:46:19Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Sun, Sep 28, 2025:\n> continuation (+) for the elements following the first paragraph if you\n> want to be guaranteed a predictable output\n\nMissing period.\n"},{"id":"527516","messageId":"xmqq4ism7eh4.fsf@gitster.g","threadId":"64221","inReplyTo":"0520e8f9caf.1759067095.git.code@khaugsbakk.name","subject":"Re: [PATCH] doc: patch-id: fix accidental literal blocks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-28T16:01:59Z","receivedAt":"2025-09-28T16:02:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"kristofferhaugsbakk@fastmail.com writes:\n\n> From: Kristoffer Haugsbakk \n>\n> The options here are apparently written with the assumption that you\n> can continue a block like e.g. a description list by maintaining the\n> same indentation level. This is not the the case; you need to use list\n> continuation (+) for the elements following the first paragraph if you\n> want to be guaranteed a predictable output\n>\n> This is kind of subtle since only the last paragraph of each option gets\n> rendered in an unintended way, namely as literal blocks. This is easier\n> to see in the HTML output since the man page output just has a slightly\n> larger indentation on these paragraphs.\n\nHmph, I've always thought that the practice breaks every paragraph\nexcept for the first one (which is the same as \"only the last\",\nonly when you have exactly 2 paragraphs; when you have more than 2,\nit makes a difference).\n\nThe changes in the diff part all look reasonable to me.\n\nThanks.\n"},{"id":"527517","messageId":"b7ded038-fc91-41cc-b241-1ace6b46069c@app.fastmail.com","threadId":"64221","inReplyTo":"xmqq4ism7eh4.fsf@gitster.g","subject":"Re: [PATCH] doc: patch-id: fix accidental literal blocks","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-09-28T19:25:26Z","receivedAt":"2025-09-28T19:25:49Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Sun, Sep 28, 2025, at 18:01, Junio C Hamano wrote:\n> kristofferhaugsbakk@fastmail.com writes:\n>\n>> From: Kristoffer Haugsbakk \n>>\n>> The options here are apparently written with the assumption that you\n>> can continue a block like e.g. a description list by maintaining the\n>> same indentation level. This is not the the case; you need to use list\n>> continuation (+) for the elements following the first paragraph if you\n>> want to be guaranteed a predictable output\n>>\n>> This is kind of subtle since only the last paragraph of each option gets\n>> rendered in an unintended way, namely as literal blocks. This is easier\n>> to see in the HTML output since the man page output just has a slightly\n>> larger indentation on these paragraphs.\n>\n> Hmph, I've always thought that the practice breaks every paragraph\n> except for the first one (which is the same as \"only the last\",\n> only when you have exactly 2 paragraphs; when you have more than 2,\n> it makes a difference).\n\nI don’t understand why but `doc-diff` agrees that these last ones are\nthe only ones affected by this change.\n"},{"id":"527518","messageId":"xmqqv7l25pxa.fsf@gitster.g","threadId":"64221","inReplyTo":"b7ded038-fc91-41cc-b241-1ace6b46069c@app.fastmail.com","subject":"Re: [PATCH] doc: patch-id: fix accidental literal blocks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-28T19:37:37Z","receivedAt":"2025-09-28T19:37:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" writes:\n\n> ...\n>>> This is kind of subtle since only the last paragraph of each option gets\n>>> rendered in an unintended way, namely as literal blocks. This is easier\n>>> to see in the HTML output since the man page output just has a slightly\n>>> larger indentation on these paragraphs.\n>>\n>> Hmph, I've always thought that the practice breaks every paragraph\n>> except for the first one (which is the same as \"only the last\",\n>> only when you have exactly 2 paragraphs; when you have more than 2,\n>> it makes a difference).\n>\n> I don’t understand why but `doc-diff` agrees that these last ones are\n> the only ones affected by this change.\n\nBut in this patch, you are not dealing with a section with three or\nmore paragraphs, are you? I think there is nothing doc-diff can\nshow you in this particular fix.\n\nFor example, the first hunk deals with\n\n\t--verbatim::\n\t\tCalculate the patch-id of the input as it is given, do not strip\n\t\tany whitespace.\n\n\t\tThis is the default if patchid.verbatim is true.\n\ntwo paragraphs, \"Calculate...\", and \"This is the default...\". It is\ncorrect that the second paragraph needs to be treated, like so:\n\n\t--verbatim::\n\t\tCalculate the patch-id of the input as it is given, do not strip\n\t\tany whitespace.\n\t+\n\tThis is the default if patchid.verbatim is true.\n\nand that is what your patch does.\n\nBut if you had three or more, e.g.,\n\n\t--verbatim::\n\t\tCalculate the patch-id of the input as it is given, do not strip\n\t\tany whitespace.\n\n\t\tThis is the default if patchid.verbatim is true.\n\n\t\tFor fun, we add a third paragraph.\n\nwould it render the first two paragraph correctly, and only the \"For\nfun, ...\" paragraph gets shown incorrectly? And would it give us a\ngood rendition to fix only the last paragraph, like so:\n\n\t--verbatim::\n\t\tCalculate the patch-id of the input as it is given, do not strip\n\t\tany whitespace.\n\n\t\tThis is the default if patchid.verbatim is true.\n\t+\n\tFor fun, we add a third paragraph.\n\nThat is what your proposed log message said, and that is what I\nwanted to double check, as from memory and experience, I am\nreasonably sure that in such a case, I had to correct it more like\n\n\t--verbatim::\n\t\tCalculate the patch-id of the input as it is given, do not strip\n\t\tany whitespace.\n\t+\n\tThis is the default if patchid.verbatim is true.\n\t+\n\tFor fun, we add a third paragraph.\n\ni.e., the second and subsequent paragraphs needed the \"a + on a line\nbyitself before the paragraph, and paragraph itself dedented\"\ntreatment.\n\nThanks.\n"},{"id":"527597","messageId":"v2-e5ad12cc3b3.1759178715.git.code@khaugsbakk.name","threadId":"64221","inReplyTo":"0520e8f9caf.1759067095.git.code@khaugsbakk.name","subject":"[PATCH v2] doc: patch-id: fix accidental literal blocks","fromName":"","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-09-29T20:47:28Z","receivedAt":"2025-09-29T20:47:51Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"From: Kristoffer Haugsbakk \n\nAll the final paragraphs on these three options are rendered as\nliteral blocks. The intent was surely to keep each of them wed to their\nrespective description list items. But the attempt at maintaining the\nindentation level of the block causes each them to be interpreted as a\ncode block, since code blocks can be represented using indentation.\n\nWe need to use list continuation (+) in order to keep them wed to\ntheir blocks.\n\nThere is also an unordered list which sandwiches two paragraphs on an\noption. We don’t need to do anything about that since it attaches to the\ndescription list item without list continuation (i.e. it is already\ncorrect). But for consistency let’s use list continuation and an open\nblock on it.\n\nSigned-off-by: Kristoffer Haugsbakk \n---\n\nNotes (series):\n v2:\n \n Rewrite the commit message. Especially with an eye towards\n explaining (and not hedging) why and how things work the way they do; in\n particular that the unordered list is already fine and doesn’t need a\n list continuation. But let’s go ahead and do it anyway since it doesn’t\n hurt and keeps things more consistent.\n \n Also describe the problem immediately instead of burying the lede/lead\n with “The options here are apparently written ...”.\n \n Also less “the the” mistakes.\n\n Documentation/git-patch-id.adoc | 43 ++++++++++++++++++---------------\n 1 file changed, 23 insertions(+), 20 deletions(-)\n\ndiff --git a/Documentation/git-patch-id.adoc b/Documentation/git-patch-id.adoc\nindex 1d15fa45d51..45da0f27acd 100644\n--- a/Documentation/git-patch-id.adoc\n+++ b/Documentation/git-patch-id.adoc\n@@ -33,27 +33,30 @@ OPTIONS\n --verbatim::\n \tCalculate the patch-id of the input as it is given, do not strip\n \tany whitespace.\n-\n-\tThis is the default if patchid.verbatim is true.\n++\n+This is the default if patchid.verbatim is true.\n \n --stable::\n \tUse a \"stable\" sum of hashes as the patch ID. With this option:\n-\t - Reordering file diffs that make up a patch does not affect the ID.\n-\t In particular, two patches produced by comparing the same two trees\n-\t with two different settings for \"-O\" result in the same\n-\t patch ID signature, thereby allowing the computed result to be used\n-\t as a key to index some meta-information about the change between\n-\t the two trees;\n-\n-\t - Result is different from the value produced by git 1.9 and older\n-\t or produced when an \"unstable\" hash (see --unstable below) is\n-\t configured - even when used on a diff output taken without any use\n-\t of \"-O\", thereby making existing databases storing such\n-\t \"unstable\" or historical patch-ids unusable.\n-\n-\t - All whitespace within the patch is ignored and does not affect the id.\n-\n-\tThis is the default if patchid.stable is set to true.\n++\n+--\n+- Reordering file diffs that make up a patch does not affect the ID.\n+ In particular, two patches produced by comparing the same two trees\n+ with two different settings for \"-O\" result in the same\n+ patch ID signature, thereby allowing the computed result to be used\n+ as a key to index some meta-information about the change between\n+ the two trees;\n+\n+- Result is different from the value produced by git 1.9 and older\n+ or produced when an \"unstable\" hash (see --unstable below) is\n+ configured - even when used on a diff output taken without any use\n+ of \"-O\", thereby making existing databases storing such\n+ \"unstable\" or historical patch-ids unusable.\n+\n+- All whitespace within the patch is ignored and does not affect the id.\n+--\n++\n+This is the default if patchid.stable is set to true.\n \n --unstable::\n \tUse an \"unstable\" hash as the patch ID. With this option,\n@@ -61,8 +64,8 @@ OPTIONS\n \tby git 1.9 and older and whitespace is ignored. Users with pre-existing\n \tdatabases storing patch-ids produced by git 1.9 and older (who do not deal\n \twith reordered patches) may want to use this option.\n-\n-\tThis is the default.\n++\n+This is the default.\n \n GIT\n ---\n\nInterdiff against v1:\n\nRange-diff against v1:\n1: 0520e8f9caf ! 1: e5ad12cc3b3 doc: patch-id: fix accidental literal blocks\n @@ Metadata\n ## Commit message ##\n doc: patch-id: fix accidental literal blocks\n \n - The options here are apparently written with the assumption that you\n - can continue a block like e.g. a description list by maintaining the\n - same indentation level. This is not the the case; you need to use list\n - continuation (+) for the elements following the first paragraph if you\n - want to be guaranteed a predictable output\n + All the final paragraphs on these three options are rendered as\n + literal blocks. The intent was surely to keep each of them wed to their\n + respective description list items. But the attempt at maintaining the\n + indentation level of the block causes each them to be interpreted as a\n + code block, since code blocks can be represented using indentation.\n \n - This is kind of subtle since only the last paragraph of each option gets\n - rendered in an unintended way, namely as literal blocks. This is easier\n - to see in the HTML output since the man page output just has a slightly\n - larger indentation on these paragraphs.\n + We need to use list continuation (+) in order to keep them wed to\n + their blocks.\n \n - Let’s use list continuation throughout, collapse the indentation in\n - front of all paragraphs except the first one, and wrap the unordered\n - list in an open block (`--`).\n + There is also an unordered list which sandwiches two paragraphs on an\n + option. We don’t need to do anything about that since it attaches to the\n + description list item without list continuation (i.e. it is already\n + correct). But for consistency let’s use list continuation and an open\n + block on it.\n \n Signed-off-by: Kristoffer Haugsbakk \n \n\nbase-commit: c44beea485f0f2feaf460e2ac87fdd5608d63cf0\n-- \n2.51.0.327.gddebdc8c038\n\n"},{"id":"527602","messageId":"xmqqzfac6gyq.fsf@gitster.g","threadId":"64221","inReplyTo":"v2-e5ad12cc3b3.1759178715.git.code@khaugsbakk.name","subject":"Re: [PATCH v2] doc: patch-id: fix accidental literal blocks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-29T22:18:05Z","receivedAt":"2025-09-29T22:18:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"kristofferhaugsbakk@fastmail.com writes:\n\n> From: Kristoffer Haugsbakk \n>\n> All the final paragraphs on these three options are rendered as\n> literal blocks. The intent was surely to keep each of them wed to their\n> respective description list items. But the attempt at maintaining the\n> indentation level of the block causes each them to be interpreted as a\n> code block, since code blocks can be represented using indentation.\n>\n> We need to use list continuation (+) in order to keep them wed to\n> their blocks.\n>\n> There is also an unordered list which sandwiches two paragraphs on an\n> option. We don’t need to do anything about that since it attaches to the\n> description list item without list continuation (i.e. it is already\n> correct). But for consistency let’s use list continuation and an open\n> block on it.\n>\n> Signed-off-by: Kristoffer Haugsbakk \n> ---\n\nThanks. Let me mark this for 'next'.\n"}]}