{"thread":{"id":"64192","subject":"doc: config/extensions.adoc: line continuation syntax error","startedAt":"2025-09-23T18:34:21Z","lastAt":"2025-10-13T15:17:33Z","messageCount":14,"participants":["Kristoffer Haugsbakk","Jean-Noël AVILA","Jeff King","Jean-Noël Avila","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"527126","messageId":"a6e4e995-fc19-465d-bd7a-c002bc0db31f@app.fastmail.com","threadId":"64192","inReplyTo":null,"subject":"doc: config/extensions.adoc: line continuation syntax error","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2025-09-23T18:34:00Z","receivedAt":"2025-09-23T18:34:21Z","isPatch":false,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"Hi\n\nSee the HTML output on e.g. latest `master` (ca2559c1 (The tenth batch,\n2025-09-18)) for `git-config.adoc`:\n\n    + For historical reasons, this extension is respected regardless of the core.repositoryFormatVersion setting.\n\nThe context is a definition item `worktreeConfig` where this is the\nsecond paragraph following a bullet list.  So I thought maybe you can\nuse:\n\n    --\n    <bullets>\n    --\n\nHere.  But we’re already inside a `--` block.  So apparently we can’t do\nthat.  I also tried a fair amount of permutations of using or not using\nline continuation in this context.\n\nThis particular level of nesting seems tricky to resolve with Asciidoc.\nMaybe someone can figure it out.  So before I forget...\n\nThanks\n\n(The Cc is because he is one of the Asciidoc experts as a FYI only)\n\n-- \nKristoffer\n"},{"id":"527141","messageId":"6196161.lOV4Wx5bFT@cayenne","threadId":"64192","inReplyTo":"a6e4e995-fc19-465d-bd7a-c002bc0db31f@app.fastmail.com","subject":"Re: doc: config/extensions.adoc: line continuation syntax error","fromName":"Jean-Noël AVILA","fromEmail":"jn.avila@free.fr","sentAt":"2025-09-23T21:08:10Z","receivedAt":"2025-09-23T21:18:10Z","isPatch":false,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"On Tuesday, 23 September 2025 20:34:00 CEST Kristoffer Haugsbakk wrote:\n> Hi\n> \n> See the HTML output on e.g. latest `master` (ca2559c1 (The tenth batch,\n> 2025-09-18)) for `git-config.adoc`:\n> \n>     + For historical reasons, this extension is respected regardless of the\n> core.repositoryFormatVersion setting.\n> \n\nAt first, I could not see the same output. It seems to be again a discrepancy \nbetween asciidoc.py and asciidoctor. Only asciidoctor is producing this \noutput, and for me, it looks like a bug in asciidoctor.\n\n\n> The context is a definition item `worktreeConfig` where this is the\n> second paragraph following a bullet list.  So I thought maybe you can\n> use:\n> \n>     --\n>     <bullets>\n>     --\n> \n> Here.  But we’re already inside a `--` block.  So apparently we can’t do\n> that.  I also tried a fair amount of permutations of using or not using\n> line continuation in this context.\n> \n> This particular level of nesting seems tricky to resolve with Asciidoc.\n> Maybe someone can figure it out.  So before I forget...\n> \n> Thanks\n> \n> (The Cc is because he is one of the Asciidoc experts as a FYI only)\n\nIndeed, open blocks cannot be nested [1]. But, the first open block is not \nnecessary as it is a workaround for the missing knowledge of multi-level \ndefinition lists.\n\n[1]: https://docs.asciidoctor.org/asciidoc/latest/blocks/open-blocks/\n#:~:text=It%20allows%20you%20to%20apply,inside%20of%20another%20open%20block.\n\nSomething along the following lines seems to work with asciidoctor while \npreserving the original paragraph nesting:\n\ndiff --git a/Documentation/config/extensions.adoc b/Documentation/config/\nextensions.adoc\nindex 829f2523fc..556eda5d12 100644\n--- a/Documentation/config/extensions.adoc\n+++ b/Documentation/config/extensions.adoc\n@@ -3,8 +3,7 @@ extensions.*::\n \t`core.repositoryFormatVersion` is not `1`. See\n \tlinkgit:gitrepository-layout[5].\n +\n---\n-compatObjectFormat::\n+compatObjectFormat:::\n \tSpecify a compatibility hash algorithm to use.  The acceptable \nvalues\n \tare `sha1` and `sha256`.  The value specified must be different from \nthe\n \tvalue of `extensions.objectFormat`.  This allows client level\n@@ -19,18 +18,18 @@ Note that the functionality enabled by this extension is \nincomplete and subject\n to change.  It currently exists only to allow development and testing of\n the underlying feature and is not designed to be enabled by end users.\n \n-noop::\n+noop:::\n \tThis extension does not change git's behavior at all. It is useful \nonly\n \tfor testing format-1 compatibility.\n +\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n \n-noop-v1::\n+noop-v1:::\n \tThis extension does not change git's behavior at all. It is useful \nonly\n \tfor testing format-1 compatibility.\n \n-objectFormat::\n+objectFormat:::\n \tSpecify the hash algorithm to use.  The acceptable values are \n`sha1` and\n \t`sha256`.  If not specified, `sha1` is assumed.\n +\n@@ -38,7 +37,7 @@ Note that this setting should only be set by linkgit:git-\ninit[1] or\n linkgit:git-clone[1].  Trying to change it after initialization will not\n work and will produce hard-to-diagnose issues.\n \n-partialClone::\n+partialClone:::\n \tWhen enabled, indicates that the repo was created with a partial \nclone\n \t(or later performed a partial fetch) and that the remote may have\n \tomitted sending certain unwanted objects.  Such a remote is called \na\n@@ -50,14 +49,14 @@ The value of this key is the name of the promisor remote.\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n \n-preciousObjects::\n+preciousObjects:::\n \tIf enabled, indicates that objects in the repository MUST NOT be \ndeleted\n \t(e.g., by `git-prune` or `git repack -d`).\n +\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n \n-refStorage::\n+refStorage:::\n \tSpecify the ref storage format to use. The acceptable values are:\n +\n include::../ref-storage-format.adoc[]\n@@ -67,13 +66,13 @@ Note that this setting should only be set by linkgit:git-\ninit[1] or\n linkgit:git-clone[1]. Trying to change it after initialization will not\n work and will produce hard-to-diagnose issues.\n \n-relativeWorktrees::\n+relativeWorktrees:::\n \tIf enabled, indicates at least one worktree has been linked with\n \trelative paths. Automatically set if a worktree has been created or\n \trepaired with either the `--relative-paths` option or with the\n \t`worktree.useRelativePaths` config set to `true`.\n \n-worktreeConfig::\n+worktreeConfig:::\n \tIf enabled, then worktrees will load config settings from the\n \t`$GIT_DIR/config.worktree` file in addition to the\n \t`$GIT_COMMON_DIR/config` file. Note that `$GIT_COMMON_DIR` and\n@@ -87,11 +86,12 @@ When enabling this extension, you must be careful to move\n certain values from the common config file to the main working tree's\n `config.worktree` file, if present:\n +\n+--\n * `core.worktree` must be moved from `$GIT_COMMON_DIR/config` to\n   `$GIT_COMMON_DIR/config.worktree`.\n * If `core.bare` is true, then it must be moved from `$GIT_COMMON_DIR/config`\n   to `$GIT_COMMON_DIR/config.worktree`.\n-\n+--\n +\n It may also be beneficial to adjust the locations of `core.sparseCheckout`\n and `core.sparseCheckoutCone` depending on your desire for customizable\n@@ -104,4 +104,3 @@ details.\n +\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n---\n\n\n\n"},{"id":"527166","messageId":"20250924005412.GB1142438@coredump.intra.peff.net","threadId":"64192","inReplyTo":"6196161.lOV4Wx5bFT@cayenne","subject":"Re: doc: config/extensions.adoc: line continuation syntax error","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-09-24T00:54:12Z","receivedAt":"2025-09-24T00:54:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 23, 2025 at 11:08:10PM +0200, Jean-Noël AVILA wrote:\n\n> Indeed, open blocks cannot be nested [1]. But, the first open block is not \n> necessary as it is a workaround for the missing knowledge of multi-level \n> definition lists.\n\nWe've run in this before, but I don't think we ever came up with a\nsatisfactory general solution.\n\nYou can find one more case with:\n\n  cd Documentation\n  ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD\n\nand searching in the pager for:\n\n  /^\\+[ ]+\\+\n\nwhich shows added lines starting with \"+\". The other one is in the\npretty-formats %(decorate) description, which is included in a few\nplaces.\n\nThere are some other hits for ASCII art, some of which I think are\nmis-rendered. But that's a separate problem. :)\n\n-Peff\n"},{"id":"527444","messageId":"20250926194022.19585-1-jn.avila@free.fr","threadId":"64192","inReplyTo":"20250924005412.GB1142438@coredump.intra.peff.net","subject":"[PATCH] doc: change the markup of paragraphs following a nested list item","fromName":"Jean-Noël Avila","fromEmail":"jn.avila@free.fr","sentAt":"2025-09-26T19:40:22Z","receivedAt":"2025-09-26T19:41:25Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Asciidoctor and asciidoc.py have different behaviors when a paragraph\nfollows a nested list item. Asciidoctor has a bug[1] that makes it add a\nstraight plus sign (+) at the beginning of the paragraph.\n\n[1]:https://github.com/asciidoctor/asciidoctor/issues/4704\n\nThis commit uses workarounds to avoid this problem by using second level\ndefinition lists and open blocks.\n\nSigned-off-by: Jean-Noël Avila <jn.avila@free.fr>\n---\n Documentation/config/extensions.adoc | 23 +++++++++++------------\n Documentation/pretty-formats.adoc    |  6 ++++--\n 2 files changed, 15 insertions(+), 14 deletions(-)\n\ndiff --git a/Documentation/config/extensions.adoc b/Documentation/config/extensions.adoc\nindex 829f2523fc..556eda5d12 100644\n--- a/Documentation/config/extensions.adoc\n+++ b/Documentation/config/extensions.adoc\n@@ -3,8 +3,7 @@ extensions.*::\n \t`core.repositoryFormatVersion` is not `1`. See\n \tlinkgit:gitrepository-layout[5].\n +\n---\n-compatObjectFormat::\n+compatObjectFormat:::\n \tSpecify a compatibility hash algorithm to use.  The acceptable values\n \tare `sha1` and `sha256`.  The value specified must be different from the\n \tvalue of `extensions.objectFormat`.  This allows client level\n@@ -19,18 +18,18 @@ Note that the functionality enabled by this extension is incomplete and subject\n to change.  It currently exists only to allow development and testing of\n the underlying feature and is not designed to be enabled by end users.\n \n-noop::\n+noop:::\n \tThis extension does not change git's behavior at all. It is useful only\n \tfor testing format-1 compatibility.\n +\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n \n-noop-v1::\n+noop-v1:::\n \tThis extension does not change git's behavior at all. It is useful only\n \tfor testing format-1 compatibility.\n \n-objectFormat::\n+objectFormat:::\n \tSpecify the hash algorithm to use.  The acceptable values are `sha1` and\n \t`sha256`.  If not specified, `sha1` is assumed.\n +\n@@ -38,7 +37,7 @@ Note that this setting should only be set by linkgit:git-init[1] or\n linkgit:git-clone[1].  Trying to change it after initialization will not\n work and will produce hard-to-diagnose issues.\n \n-partialClone::\n+partialClone:::\n \tWhen enabled, indicates that the repo was created with a partial clone\n \t(or later performed a partial fetch) and that the remote may have\n \tomitted sending certain unwanted objects.  Such a remote is called a\n@@ -50,14 +49,14 @@ The value of this key is the name of the promisor remote.\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n \n-preciousObjects::\n+preciousObjects:::\n \tIf enabled, indicates that objects in the repository MUST NOT be deleted\n \t(e.g., by `git-prune` or `git repack -d`).\n +\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n \n-refStorage::\n+refStorage:::\n \tSpecify the ref storage format to use. The acceptable values are:\n +\n include::../ref-storage-format.adoc[]\n@@ -67,13 +66,13 @@ Note that this setting should only be set by linkgit:git-init[1] or\n linkgit:git-clone[1]. Trying to change it after initialization will not\n work and will produce hard-to-diagnose issues.\n \n-relativeWorktrees::\n+relativeWorktrees:::\n \tIf enabled, indicates at least one worktree has been linked with\n \trelative paths. Automatically set if a worktree has been created or\n \trepaired with either the `--relative-paths` option or with the\n \t`worktree.useRelativePaths` config set to `true`.\n \n-worktreeConfig::\n+worktreeConfig:::\n \tIf enabled, then worktrees will load config settings from the\n \t`$GIT_DIR/config.worktree` file in addition to the\n \t`$GIT_COMMON_DIR/config` file. Note that `$GIT_COMMON_DIR` and\n@@ -87,11 +86,12 @@ When enabling this extension, you must be careful to move\n certain values from the common config file to the main working tree's\n `config.worktree` file, if present:\n +\n+--\n * `core.worktree` must be moved from `$GIT_COMMON_DIR/config` to\n   `$GIT_COMMON_DIR/config.worktree`.\n * If `core.bare` is true, then it must be moved from `$GIT_COMMON_DIR/config`\n   to `$GIT_COMMON_DIR/config.worktree`.\n-\n+--\n +\n It may also be beneficial to adjust the locations of `core.sparseCheckout`\n and `core.sparseCheckoutCone` depending on your desire for customizable\n@@ -104,4 +104,3 @@ details.\n +\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n---\ndiff --git a/Documentation/pretty-formats.adoc b/Documentation/pretty-formats.adoc\nindex 618ddc4a0c..2121e8e1df 100644\n--- a/Documentation/pretty-formats.adoc\n+++ b/Documentation/pretty-formats.adoc\n@@ -232,7 +232,7 @@ ref names with custom decorations. The `decorate` string may be followed by a\n colon and zero or more comma-separated options. Option values may contain\n literal formatting codes. These must be used for commas (`%x2C`) and closing\n parentheses (`%x29`), due to their role in the option syntax.\n-+\n+\n ** `prefix=<value>`: Shown before the list of ref names.  Defaults to \"{nbsp}++(++\".\n ** `suffix=<value>`: Shown after the list of ref names.  Defaults to \"+)+\".\n ** `separator=<value>`: Shown between ref names.  Defaults to \"+,+{nbsp}\".\n@@ -241,10 +241,12 @@ parentheses (`%x29`), due to their role in the option syntax.\n ** `tag=<value>`: Shown before tag names. Defaults to \"`tag:`{nbsp}\".\n \n +\n+--\n For example, to produce decorations with no wrapping\n or tag annotations, and spaces as separators:\n-+\n+\n ++%(decorate:prefix=,suffix=,tag=,separator= )++\n+--\n \n ++%(describe++`[:<option>,...]`++)++::\n human-readable name, like linkgit:git-describe[1]; empty string for\n-- \n2.51.0\n\n"},{"id":"527445","messageId":"xmqq5xd5aqa5.fsf@gitster.g","threadId":"64192","inReplyTo":"20250926194022.19585-1-jn.avila@free.fr","subject":"Re: [PATCH] doc: change the markup of paragraphs following a nested list item","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-26T20:54:10Z","receivedAt":"2025-09-26T20:54:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noël Avila <jn.avila@free.fr> writes:\n\n> Asciidoctor and asciidoc.py have different behaviors when a paragraph\n> follows a nested list item. Asciidoctor has a bug[1] that makes it add a\n> straight plus sign (+) at the beginning of the paragraph.\n>\n> [1]:https://github.com/asciidoctor/asciidoctor/issues/4704\n\nI read both the above introductory paragraph and the Asciidoctor\nissue, but couldn't figure out what a \"straight plus sign\" is.  Even\nif it were a typo of \"stray plus sign\" (which I am guessing but with\nvery low confidence), I do not see it at\n\n  https://git.github.io/htmldocs/git-config.html#:~:text=extensions.*,compatObjectFormat\n\nwhich I think is rendered via Asciidoctor.\n\nCould you rephrase to clarify?\n\nThanks.\n\n\n> diff --git a/Documentation/config/extensions.adoc b/Documentation/config/extensions.adoc\n> index 829f2523fc..556eda5d12 100644\n> --- a/Documentation/config/extensions.adoc\n> +++ b/Documentation/config/extensions.adoc\n> @@ -3,8 +3,7 @@ extensions.*::\n>  \t`core.repositoryFormatVersion` is not `1`. See\n>  \tlinkgit:gitrepository-layout[5].\n>  +\n> ---\n> -compatObjectFormat::\n> +compatObjectFormat:::\n>  \tSpecify a compatibility hash algorithm to use.  The acceptable values\n>  \tare `sha1` and `sha256`.  The value specified must be different from the\n>  \tvalue of `extensions.objectFormat`.  This allows client level\n> @@ -19,18 +18,18 @@ Note that the functionality enabled by this extension is incomplete and subject\n>  to change.  It currently exists only to allow development and testing of\n>  the underlying feature and is not designed to be enabled by end users.\n>  \n> -noop::\n> +noop:::\n>  \tThis extension does not change git's behavior at all. It is useful only\n>  \tfor testing format-1 compatibility.\n>  +\n>  For historical reasons, this extension is respected regardless of the\n>  `core.repositoryFormatVersion` setting.\n>  \n> -noop-v1::\n> +noop-v1:::\n>  \tThis extension does not change git's behavior at all. It is useful only\n>  \tfor testing format-1 compatibility.\n>  \n> -objectFormat::\n> +objectFormat:::\n>  \tSpecify the hash algorithm to use.  The acceptable values are `sha1` and\n>  \t`sha256`.  If not specified, `sha1` is assumed.\n>  +\n> @@ -38,7 +37,7 @@ Note that this setting should only be set by linkgit:git-init[1] or\n>  linkgit:git-clone[1].  Trying to change it after initialization will not\n>  work and will produce hard-to-diagnose issues.\n>  \n> -partialClone::\n> +partialClone:::\n>  \tWhen enabled, indicates that the repo was created with a partial clone\n>  \t(or later performed a partial fetch) and that the remote may have\n>  \tomitted sending certain unwanted objects.  Such a remote is called a\n> @@ -50,14 +49,14 @@ The value of this key is the name of the promisor remote.\n>  For historical reasons, this extension is respected regardless of the\n>  `core.repositoryFormatVersion` setting.\n>  \n> -preciousObjects::\n> +preciousObjects:::\n>  \tIf enabled, indicates that objects in the repository MUST NOT be deleted\n>  \t(e.g., by `git-prune` or `git repack -d`).\n>  +\n>  For historical reasons, this extension is respected regardless of the\n>  `core.repositoryFormatVersion` setting.\n>  \n> -refStorage::\n> +refStorage:::\n>  \tSpecify the ref storage format to use. The acceptable values are:\n>  +\n>  include::../ref-storage-format.adoc[]\n> @@ -67,13 +66,13 @@ Note that this setting should only be set by linkgit:git-init[1] or\n>  linkgit:git-clone[1]. Trying to change it after initialization will not\n>  work and will produce hard-to-diagnose issues.\n>  \n> -relativeWorktrees::\n> +relativeWorktrees:::\n>  \tIf enabled, indicates at least one worktree has been linked with\n>  \trelative paths. Automatically set if a worktree has been created or\n>  \trepaired with either the `--relative-paths` option or with the\n>  \t`worktree.useRelativePaths` config set to `true`.\n>  \n> -worktreeConfig::\n> +worktreeConfig:::\n>  \tIf enabled, then worktrees will load config settings from the\n>  \t`$GIT_DIR/config.worktree` file in addition to the\n>  \t`$GIT_COMMON_DIR/config` file. Note that `$GIT_COMMON_DIR` and\n> @@ -87,11 +86,12 @@ When enabling this extension, you must be careful to move\n>  certain values from the common config file to the main working tree's\n>  `config.worktree` file, if present:\n>  +\n> +--\n>  * `core.worktree` must be moved from `$GIT_COMMON_DIR/config` to\n>    `$GIT_COMMON_DIR/config.worktree`.\n>  * If `core.bare` is true, then it must be moved from `$GIT_COMMON_DIR/config`\n>    to `$GIT_COMMON_DIR/config.worktree`.\n> -\n> +--\n>  +\n>  It may also be beneficial to adjust the locations of `core.sparseCheckout`\n>  and `core.sparseCheckoutCone` depending on your desire for customizable\n> @@ -104,4 +104,3 @@ details.\n>  +\n>  For historical reasons, this extension is respected regardless of the\n>  `core.repositoryFormatVersion` setting.\n> ---\n> diff --git a/Documentation/pretty-formats.adoc b/Documentation/pretty-formats.adoc\n> index 618ddc4a0c..2121e8e1df 100644\n> --- a/Documentation/pretty-formats.adoc\n> +++ b/Documentation/pretty-formats.adoc\n> @@ -232,7 +232,7 @@ ref names with custom decorations. The `decorate` string may be followed by a\n>  colon and zero or more comma-separated options. Option values may contain\n>  literal formatting codes. These must be used for commas (`%x2C`) and closing\n>  parentheses (`%x29`), due to their role in the option syntax.\n> -+\n> +\n>  ** `prefix=<value>`: Shown before the list of ref names.  Defaults to \"{nbsp}++(++\".\n>  ** `suffix=<value>`: Shown after the list of ref names.  Defaults to \"+)+\".\n>  ** `separator=<value>`: Shown between ref names.  Defaults to \"+,+{nbsp}\".\n> @@ -241,10 +241,12 @@ parentheses (`%x29`), due to their role in the option syntax.\n>  ** `tag=<value>`: Shown before tag names. Defaults to \"`tag:`{nbsp}\".\n>  \n>  +\n> +--\n>  For example, to produce decorations with no wrapping\n>  or tag annotations, and spaces as separators:\n> -+\n> +\n>  ++%(decorate:prefix=,suffix=,tag=,separator= )++\n> +--\n>  \n>  ++%(describe++`[:<option>,...]`++)++::\n>  human-readable name, like linkgit:git-describe[1]; empty string for\n"},{"id":"527495","messageId":"20250927195032.37223-1-jn.avila@free.fr","threadId":"64192","inReplyTo":"xmqq5xd5aqa5.fsf@gitster.g","subject":"[PATCH v2] doc: change the markup of paragraphs following a nested list item","fromName":"Jean-Noël Avila","fromEmail":"jn.avila@free.fr","sentAt":"2025-09-27T19:39:45Z","receivedAt":"2025-09-27T19:50:59Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Asciidoctor and asciidoc.py have different behaviors when a paragraph\nfollows a nested list item. Asciidoctor has a bug[1] that makes it keep a\nplus sign (+) used to attached paragraphs at the beginning of the paragraph.\n\nThis commit uses workarounds to avoid this problem by using second level\ndefinition lists and open blocks.\n\n[1]:https://github.com/asciidoctor/asciidoctor/issues/4704\n\nSigned-off-by: Jean-Noël Avila <jn.avila@free.fr>\n---\n\nSorry for the straight/stray confusion. It is saner to remove it.\n\nThe first occurrence of the described issue is a few lines below where you\nlooked at:\n\nhttps://git.github.io/htmldocs/git-config.html#:~:text=+%20For%20historical\n\nalso see the second one:\n\nhttps://git.github.io/htmldocs/git-log.html#:~:text=%2B%20%25(decorate\n\nAnd big thank you to peff for teaching doc-diff.\n\n Documentation/config/extensions.adoc | 23 +++++++++++------------\n Documentation/pretty-formats.adoc    |  6 ++++--\n 2 files changed, 15 insertions(+), 14 deletions(-)\n\ndiff --git a/Documentation/config/extensions.adoc b/Documentation/config/extensions.adoc\nindex 829f2523fc..556eda5d12 100644\n--- a/Documentation/config/extensions.adoc\n+++ b/Documentation/config/extensions.adoc\n@@ -3,8 +3,7 @@ extensions.*::\n \t`core.repositoryFormatVersion` is not `1`. See\n \tlinkgit:gitrepository-layout[5].\n +\n---\n-compatObjectFormat::\n+compatObjectFormat:::\n \tSpecify a compatibility hash algorithm to use.  The acceptable values\n \tare `sha1` and `sha256`.  The value specified must be different from the\n \tvalue of `extensions.objectFormat`.  This allows client level\n@@ -19,18 +18,18 @@ Note that the functionality enabled by this extension is incomplete and subject\n to change.  It currently exists only to allow development and testing of\n the underlying feature and is not designed to be enabled by end users.\n \n-noop::\n+noop:::\n \tThis extension does not change git's behavior at all. It is useful only\n \tfor testing format-1 compatibility.\n +\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n \n-noop-v1::\n+noop-v1:::\n \tThis extension does not change git's behavior at all. It is useful only\n \tfor testing format-1 compatibility.\n \n-objectFormat::\n+objectFormat:::\n \tSpecify the hash algorithm to use.  The acceptable values are `sha1` and\n \t`sha256`.  If not specified, `sha1` is assumed.\n +\n@@ -38,7 +37,7 @@ Note that this setting should only be set by linkgit:git-init[1] or\n linkgit:git-clone[1].  Trying to change it after initialization will not\n work and will produce hard-to-diagnose issues.\n \n-partialClone::\n+partialClone:::\n \tWhen enabled, indicates that the repo was created with a partial clone\n \t(or later performed a partial fetch) and that the remote may have\n \tomitted sending certain unwanted objects.  Such a remote is called a\n@@ -50,14 +49,14 @@ The value of this key is the name of the promisor remote.\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n \n-preciousObjects::\n+preciousObjects:::\n \tIf enabled, indicates that objects in the repository MUST NOT be deleted\n \t(e.g., by `git-prune` or `git repack -d`).\n +\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n \n-refStorage::\n+refStorage:::\n \tSpecify the ref storage format to use. The acceptable values are:\n +\n include::../ref-storage-format.adoc[]\n@@ -67,13 +66,13 @@ Note that this setting should only be set by linkgit:git-init[1] or\n linkgit:git-clone[1]. Trying to change it after initialization will not\n work and will produce hard-to-diagnose issues.\n \n-relativeWorktrees::\n+relativeWorktrees:::\n \tIf enabled, indicates at least one worktree has been linked with\n \trelative paths. Automatically set if a worktree has been created or\n \trepaired with either the `--relative-paths` option or with the\n \t`worktree.useRelativePaths` config set to `true`.\n \n-worktreeConfig::\n+worktreeConfig:::\n \tIf enabled, then worktrees will load config settings from the\n \t`$GIT_DIR/config.worktree` file in addition to the\n \t`$GIT_COMMON_DIR/config` file. Note that `$GIT_COMMON_DIR` and\n@@ -87,11 +86,12 @@ When enabling this extension, you must be careful to move\n certain values from the common config file to the main working tree's\n `config.worktree` file, if present:\n +\n+--\n * `core.worktree` must be moved from `$GIT_COMMON_DIR/config` to\n   `$GIT_COMMON_DIR/config.worktree`.\n * If `core.bare` is true, then it must be moved from `$GIT_COMMON_DIR/config`\n   to `$GIT_COMMON_DIR/config.worktree`.\n-\n+--\n +\n It may also be beneficial to adjust the locations of `core.sparseCheckout`\n and `core.sparseCheckoutCone` depending on your desire for customizable\n@@ -104,4 +104,3 @@ details.\n +\n For historical reasons, this extension is respected regardless of the\n `core.repositoryFormatVersion` setting.\n---\ndiff --git a/Documentation/pretty-formats.adoc b/Documentation/pretty-formats.adoc\nindex 618ddc4a0c..2121e8e1df 100644\n--- a/Documentation/pretty-formats.adoc\n+++ b/Documentation/pretty-formats.adoc\n@@ -232,7 +232,7 @@ ref names with custom decorations. The `decorate` string may be followed by a\n colon and zero or more comma-separated options. Option values may contain\n literal formatting codes. These must be used for commas (`%x2C`) and closing\n parentheses (`%x29`), due to their role in the option syntax.\n-+\n+\n ** `prefix=<value>`: Shown before the list of ref names.  Defaults to \"{nbsp}++(++\".\n ** `suffix=<value>`: Shown after the list of ref names.  Defaults to \"+)+\".\n ** `separator=<value>`: Shown between ref names.  Defaults to \"+,+{nbsp}\".\n@@ -241,10 +241,12 @@ parentheses (`%x29`), due to their role in the option syntax.\n ** `tag=<value>`: Shown before tag names. Defaults to \"`tag:`{nbsp}\".\n \n +\n+--\n For example, to produce decorations with no wrapping\n or tag annotations, and spaces as separators:\n-+\n+\n ++%(decorate:prefix=,suffix=,tag=,separator= )++\n+--\n \n ++%(describe++`[:<option>,...]`++)++::\n human-readable name, like linkgit:git-describe[1]; empty string for\n-- \n2.51.0\n\n"},{"id":"527512","messageId":"xmqqo6qu7fq2.fsf@gitster.g","threadId":"64192","inReplyTo":"20250927195032.37223-1-jn.avila@free.fr","subject":"Re: [PATCH v2] doc: change the markup of paragraphs following a nested list item","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-28T15:35:01Z","receivedAt":"2025-09-28T15:35:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noël Avila <jn.avila@free.fr> writes:\n\n> Asciidoctor and asciidoc.py have different behaviors when a paragraph\n> follows a nested list item. Asciidoctor has a bug[1] that makes it keep a\n> plus sign (+) used to attached paragraphs at the beginning of the paragraph.\n>\n> This commit uses workarounds to avoid this problem by using second level\n> definition lists and open blocks.\n>\n> [1]:https://github.com/asciidoctor/asciidoctor/issues/4704\n>\n> Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>\n> ---\n>\n> Sorry for the straight/stray confusion. It is saner to remove it.\n>\n> The first occurrence of the described issue is a few lines below where you\n> looked at:\n>\n> https://git.github.io/htmldocs/git-config.html#:~:text=+%20For%20historical\n>\n> also see the second one:\n>\n> https://git.github.io/htmldocs/git-log.html#:~:text=%2B%20%25(decorate\n>\n> And big thank you to peff for teaching doc-diff.\n\nThanks!\n"},{"id":"527863","messageId":"20251003031113.GA6381@coredump.intra.peff.net","threadId":"64192","inReplyTo":"20250927195032.37223-1-jn.avila@free.fr","subject":"Re: [PATCH v2] doc: change the markup of paragraphs following a nested list item","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-10-03T03:11:13Z","receivedAt":"2025-10-03T03:11:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 27, 2025 at 09:39:45PM +0200, Jean-Noël Avila wrote:\n\n> Asciidoctor and asciidoc.py have different behaviors when a paragraph\n> follows a nested list item. Asciidoctor has a bug[1] that makes it keep a\n> plus sign (+) used to attached paragraphs at the beginning of the paragraph.\n> \n> This commit uses workarounds to avoid this problem by using second level\n> definition lists and open blocks.\n\nI think this is mostly making things better, but there is one curiosity.\n\nLooking at:\n\n  ./doc-diff HEAD^ HEAD\n\nthere are no changes with asciidoc, which is good.\n\nLooking at:\n\n  ./doc-diff --asciidoctor HEAD^ HEAD\n\nmost of the changes are like:\n\n  @@ -3187,7 +3187,7 @@ CONFIGURATION FILE\n                  specify the sparsity for each worktree independently. See git-\n                  sparse-checkout(1) for more details.\n  \n  -               + For historical reasons, this extension is respected regardless\n  +               For historical reasons, this extension is respected regardless\n                  of the core.repositoryFormatVersion setting.\n\nwhich is fixing up the bug. Good. But then there's also this hunk in\ngit-config.1:\n\n  @@ -3148,9 +3148,9 @@ CONFIGURATION FILE\n                  •   reftable for the reftable format. This format is\n                      experimental and its internals are subject to change.\n  \n  -               Note that this setting should only be set by git-init(1) or git-\n  -               clone(1). Trying to change it after initialization will not work\n  -               and will produce hard-to-diagnose issues.\n  +           Note that this setting should only be set by git-init(1) or git-\n  +           clone(1). Trying to change it after initialization will not work and\n  +           will produce hard-to-diagnose issues.\n  \n              relativeWorktrees\n                  If enabled, indicates at least one worktree has been linked with\n\nwhich I think is wrong? Looking at the end result with more context, it\nis:\n\n             refStorage\n                 Specify the ref storage format to use. The acceptable\n                 values are:\n  \n                 •   files for loose files with packed-refs. This is the\n                     default.\n  \n                 •   reftable for the reftable format. This format is\n                     experimental and its internals are subject to\n                     change.\n  \n             Note that this setting should only be set by git-init(1) or\n             git-clone(1). Trying to change it after initialization will\n             not work and will produce hard-to-diagnose issues.\n\nSo that \"Note that...\" paragraph is attached to the refStorage\ndefinition, and should be indented to the same level as \"Specify...\".\n\nEven more interesting, I think asciidoc gets this wrong both before and\nafter your patch!\n\nLooking at the source, there is an extra blank line, which might be\nconfusing things. This seems to help both asciidoc and asciidoctor do\nthe right thing:\n\ndiff --git a/Documentation/config/extensions.adoc b/Documentation/config/extensions.adoc\nindex 556eda5d12..110976ad60 100644\n--- a/Documentation/config/extensions.adoc\n+++ b/Documentation/config/extensions.adoc\n@@ -60,7 +60,6 @@ refStorage:::\n \tSpecify the ref storage format to use. The acceptable values are:\n +\n include::../ref-storage-format.adoc[]\n-\n +\n Note that this setting should only be set by linkgit:git-init[1] or\n linkgit:git-clone[1]. Trying to change it after initialization will not\n\nNot sure if we'd want to squash that in, or do it as a fix on top, or\neven as a preparatory patch (since it does fix a real problem in the\nasciidoc version, AFAICT).\n\n-Peff\n"},{"id":"527865","messageId":"20251003034134.GA625140@coredump.intra.peff.net","threadId":"64192","inReplyTo":"20251003031113.GA6381@coredump.intra.peff.net","subject":"Re: [PATCH v2] doc: change the markup of paragraphs following a nested list item","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-10-03T03:41:34Z","receivedAt":"2025-10-03T03:41:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 02, 2025 at 11:11:14PM -0400, Jeff King wrote:\n\n> which I think is wrong? Looking at the end result with more context, it\n> is:\n> \n>              refStorage\n>                  Specify the ref storage format to use. The acceptable\n>                  values are:\n>   \n>                  •   files for loose files with packed-refs. This is the\n>                      default.\n>   \n>                  •   reftable for the reftable format. This format is\n>                      experimental and its internals are subject to\n>                      change.\n>   \n>              Note that this setting should only be set by git-init(1) or\n>              git-clone(1). Trying to change it after initialization will\n>              not work and will produce hard-to-diagnose issues.\n> \n> So that \"Note that...\" paragraph is attached to the refStorage\n> definition, and should be indented to the same level as \"Specify...\".\n> \n> Even more interesting, I think asciidoc gets this wrong both before and\n> after your patch!\n\nSorry, this is incorrect. Rendering with regular asciidoc does produce\nthe right output already.\n\nThe patch I showed to drop the extra newline turns that final paragraph\ninto a continuation of the second bullet point. So it is wrong for both\nasciidoc (which is already correct) and for asciidoctor (which indents\ntoo little, but after my proposed patch indents too much).\n\nThat's a little hard to parse, so here's my attempt at showing visually.\nThe rendered output before that final paragraph looks something like\nthis, with markers 1-3 showing possible indentation levels:\n\n  refStorage\n      Specify ...\n\n      •   files ...\n\n      •   reftable ...\n\n  (1) a peer of \"refStorage\" in the definition list\n      (2) a continuation paragraph in the \"refStorage\" definition\n          (3) a continuation paragraph in the second bullet point\n\nThe paragraph \"Note that...\" should be at indentation level 2, and\ncurrently is for both asciidoc and asciidoctor. After your patch it is\nunchanged in asciidoc and at indentation level 1 in asciidoctor.\n\nMy proposed patch (which is garbage) moves it to indentation level 3 in\nboth.\n\nI think to appease both systems we need to put the inner bulleted list\ninside a block. I think that is OK in this case because there is no\ninner block marker to worry about. So:\n\ndiff --git a/Documentation/config/extensions.adoc b/Documentation/config/extensions.adoc\nindex 49a7598ca5..aaea8c107f 100644\n--- a/Documentation/config/extensions.adoc\n+++ b/Documentation/config/extensions.adoc\n@@ -55,8 +55,9 @@ For historical reasons, this extension is respected regardless of the\n refStorage:::\n \tSpecify the ref storage format to use. The acceptable values are:\n +\n+--\n include::../ref-storage-format.adoc[]\n-\n+--\n +\n Note that this setting should only be set by linkgit:git-init[1] or\n linkgit:git-clone[1]. Trying to change it after initialization will not\n\non top of your patch seems to do the right thing (no change in asciidoc,\nand eliminating the regression from your patch). It's a little gross\nbecause we are reaching across the include to realize that\nref-storage-format.adoc contains a list that needs to go into its own\nblock. I wonder if asciidoc implicitly opens a new block for an include\nbut asciidoctor doesn't. But at any rate, this is the only way I could\ncome up with for both to render correctly.\n\n-Peff\n"},{"id":"527885","messageId":"xmqqfrc0uews.fsf@gitster.g","threadId":"64192","inReplyTo":"20251003034134.GA625140@coredump.intra.peff.net","subject":"Re: [PATCH v2] doc: change the markup of paragraphs following a nested list item","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-03T16:29:55Z","receivedAt":"2025-10-03T16:29:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I think to appease both systems we need to put the inner bulleted list\n> inside a block. I think that is OK in this case because there is no\n> inner block marker to worry about. So:\n>\n> diff --git a/Documentation/config/extensions.adoc b/Documentation/config/extensions.adoc\n> index 49a7598ca5..aaea8c107f 100644\n> --- a/Documentation/config/extensions.adoc\n> +++ b/Documentation/config/extensions.adoc\n> @@ -55,8 +55,9 @@ For historical reasons, this extension is respected regardless of the\n>  refStorage:::\n>  \tSpecify the ref storage format to use. The acceptable values are:\n>  +\n> +--\n>  include::../ref-storage-format.adoc[]\n> -\n> +--\n>  +\n>  Note that this setting should only be set by linkgit:git-init[1] or\n>  linkgit:git-clone[1]. Trying to change it after initialization will not\n>\n> on top of your patch seems to do the right thing (no change in asciidoc,\n> and eliminating the regression from your patch). It's a little gross\n> because we are reaching across the include to realize that\n> ref-storage-format.adoc contains a list that needs to go into its own\n> block. I wonder if asciidoc implicitly opens a new block for an include\n> but asciidoctor doesn't. But at any rate, this is the only way I could\n> come up with for both to render correctly.\n\nSounds good.  Thanks.\n\n"},{"id":"527917","messageId":"2239952.irdbgypaU6@cayenne","threadId":"64192","inReplyTo":"20251003034134.GA625140@coredump.intra.peff.net","subject":"Re: [PATCH v2] doc: change the markup of paragraphs following a nested list item","fromName":"Jean-Noël AVILA","fromEmail":"jn.avila@free.fr","sentAt":"2025-10-04T17:31:29Z","receivedAt":"2025-10-04T17:31:34Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"On Friday, 3 October 2025 05:41:34 CEST Jeff King wrote:\n> On Thu, Oct 02, 2025 at 11:11:14PM -0400, Jeff King wrote:\n> > which I think is wrong? Looking at the end result with more context, it\n> > \n> > is:\n> >              refStorage\n> >              \n> >                  Specify the ref storage format to use. The acceptable\n> >                  values are:\n> >                  \n> >                  •   files for loose files with packed-refs. This is the\n> >                  \n> >                      default.\n> >                  \n> >                  •   reftable for the reftable format. This format is\n> >                  \n> >                      experimental and its internals are subject to\n> >                      change.\n> >              \n> >              Note that this setting should only be set by git-init(1) or\n> >              git-clone(1). Trying to change it after initialization will\n> >              not work and will produce hard-to-diagnose issues.\n> > \n> > So that \"Note that...\" paragraph is attached to the refStorage\n> > definition, and should be indented to the same level as \"Specify...\".\n> > \n> > Even more interesting, I think asciidoc gets this wrong both before and\n> > after your patch!\n> \n> Sorry, this is incorrect. Rendering with regular asciidoc does produce\n> the right output already.\n> \n> The patch I showed to drop the extra newline turns that final paragraph\n> into a continuation of the second bullet point. So it is wrong for both\n> asciidoc (which is already correct) and for asciidoctor (which indents\n> too little, but after my proposed patch indents too much).\n> \n> That's a little hard to parse, so here's my attempt at showing visually.\n> The rendered output before that final paragraph looks something like\n> this, with markers 1-3 showing possible indentation levels:\n> \n>   refStorage\n>       Specify ...\n> \n>       •   files ...\n> \n>       •   reftable ...\n> \n>   (1) a peer of \"refStorage\" in the definition list\n>       (2) a continuation paragraph in the \"refStorage\" definition\n>           (3) a continuation paragraph in the second bullet point\n> \n> The paragraph \"Note that...\" should be at indentation level 2, and\n> currently is for both asciidoc and asciidoctor. After your patch it is\n> unchanged in asciidoc and at indentation level 1 in asciidoctor.\n> \n> My proposed patch (which is garbage) moves it to indentation level 3 in\n> both.\n> \n> I think to appease both systems we need to put the inner bulleted list\n> inside a block. I think that is OK in this case because there is no\n> inner block marker to worry about. So:\n> \n> diff --git a/Documentation/config/extensions.adoc\n> b/Documentation/config/extensions.adoc index 49a7598ca5..aaea8c107f 100644\n> --- a/Documentation/config/extensions.adoc\n> +++ b/Documentation/config/extensions.adoc\n> @@ -55,8 +55,9 @@ For historical reasons, this extension is respected \nregardless of\n> the refStorage:::\n>  \tSpecify the ref storage format to use. The acceptable values are:\n>  +\n> +--\n>  include::../ref-storage-format.adoc[]\n> -\n> +--\n>  +\n>  Note that this setting should only be set by linkgit:git-init[1] or\n>  linkgit:git-clone[1]. Trying to change it after initialization will not\n> \n> on top of your patch seems to do the right thing (no change in asciidoc,\n> and eliminating the regression from your patch). It's a little gross\n> because we are reaching across the include to realize that\n> ref-storage-format.adoc contains a list that needs to go into its own\n> block. I wonder if asciidoc implicitly opens a new block for an include\n> but asciidoctor doesn't. But at any rate, this is the only way I could\n> come up with for both to render correctly.\n> \n> -Peff\n\n\nThank you for cross-checking. This is indeed almost impossible to mechanize \nsuch testing at the moment.\n\nJN\n\n\n\n"},{"id":"528518","messageId":"xmqqo6qeag9n.fsf@gitster.g","threadId":"64192","inReplyTo":"2239952.irdbgypaU6@cayenne","subject":"Re: [PATCH v2] doc: change the markup of paragraphs following a nested list item","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-10T16:11:16Z","receivedAt":"2025-10-10T16:11:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noël AVILA <jn.avila@free.fr> writes:\n\n> On Friday, 3 October 2025 05:41:34 CEST Jeff King wrote:\n>> On Thu, Oct 02, 2025 at 11:11:14PM -0400, Jeff King wrote:\n>> ...\n>> I think to appease both systems we need to put the inner bulleted list\n>> inside a block. I think that is OK in this case because there is no\n>> inner block marker to worry about. So:\n>> \n>> diff --git a/Documentation/config/extensions.adoc\n>> b/Documentation/config/extensions.adoc index 49a7598ca5..aaea8c107f 100644\n>> --- a/Documentation/config/extensions.adoc\n>> +++ b/Documentation/config/extensions.adoc\n>> @@ -55,8 +55,9 @@ For historical reasons, this extension is respected \n> regardless of\n>> the refStorage:::\n>>  \tSpecify the ref storage format to use. The acceptable values are:\n>>  +\n>> +--\n>>  include::../ref-storage-format.adoc[]\n>> -\n>> +--\n>>  +\n>>  Note that this setting should only be set by linkgit:git-init[1] or\n>>  linkgit:git-clone[1]. Trying to change it after initialization will not\n>> \n>> on top of your patch seems to do the right thing (no change in asciidoc,\n>> and eliminating the regression from your patch). It's a little gross\n>> because we are reaching across the include to realize that\n>> ref-storage-format.adoc contains a list that needs to go into its own\n>> block. I wonder if asciidoc implicitly opens a new block for an include\n>> but asciidoctor doesn't. But at any rate, this is the only way I could\n>> come up with for both to render correctly.\n>\n> Thank you for cross-checking. This is indeed almost impossible to mechanize \n> such testing at the moment.\n\nThanks, both.  \n\nSo we'd see an update to this (I think this is already in 'next')?\n\n\n"},{"id":"528541","messageId":"20251010222304.GA2007405@coredump.intra.peff.net","threadId":"64192","inReplyTo":"xmqqo6qeag9n.fsf@gitster.g","subject":"Re: [PATCH v2] doc: change the markup of paragraphs following a nested list item","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-10-10T22:23:04Z","receivedAt":"2025-10-10T22:23:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 10, 2025 at 09:11:16AM -0700, Junio C Hamano wrote:\n\n> >> diff --git a/Documentation/config/extensions.adoc\n> >> b/Documentation/config/extensions.adoc index 49a7598ca5..aaea8c107f 100644\n> >> --- a/Documentation/config/extensions.adoc\n> >> +++ b/Documentation/config/extensions.adoc\n> >> @@ -55,8 +55,9 @@ For historical reasons, this extension is respected \n> > regardless of\n> >> the refStorage:::\n> >>  \tSpecify the ref storage format to use. The acceptable values are:\n> >>  +\n> >> +--\n> >>  include::../ref-storage-format.adoc[]\n> >> -\n> >> +--\n> >>  +\n> >>  Note that this setting should only be set by linkgit:git-init[1] or\n> >>  linkgit:git-clone[1]. Trying to change it after initialization will not\n> >> \n> >> on top of your patch seems to do the right thing (no change in asciidoc,\n> >> and eliminating the regression from your patch). It's a little gross\n> >> because we are reaching across the include to realize that\n> >> ref-storage-format.adoc contains a list that needs to go into its own\n> >> block. I wonder if asciidoc implicitly opens a new block for an include\n> >> but asciidoctor doesn't. But at any rate, this is the only way I could\n> >> come up with for both to render correctly.\n> >\n> > Thank you for cross-checking. This is indeed almost impossible to mechanize \n> > such testing at the moment.\n> \n> Thanks, both.  \n> \n> So we'd see an update to this (I think this is already in 'next')?\n\nI think we already did, in:\n\n  https://lore.kernel.org/git/20251007082223.GA3336685@coredump.intra.peff.net/\n\nand you queued that on the topic (and merged it to next already). Or am\nI misunderstanding the question?\n\n-Peff\n"},{"id":"528631","messageId":"xmqq4is24yr9.fsf@gitster.g","threadId":"64192","inReplyTo":"20251010222304.GA2007405@coredump.intra.peff.net","subject":"Re: [PATCH v2] doc: change the markup of paragraphs following a nested list item","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-13T15:17:30Z","receivedAt":"2025-10-13T15:17:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I think we already did, in:\n>\n>   https://lore.kernel.org/git/20251007082223.GA3336685@coredump.intra.peff.net/\n>\n> and you queued that on the topic (and merged it to next already).\n\nThanks, indeed we have 84a6bf79 (doc: fix indentation of refStorage\nitem in git-config(1), 2025-10-07) already on the topic.\n\n\n"}]}