git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jean-Noël AVILA" <jn.avila@free.fr>
To: git@vger.kernel.org, Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: doc: config/extensions.adoc: line continuation syntax error
Date: Tue, 23 Sep 2025 23:08:10 +0200	[thread overview]
Message-ID: <6196161.lOV4Wx5bFT@cayenne> (raw)
In-Reply-To: <a6e4e995-fc19-465d-bd7a-c002bc0db31f@app.fastmail.com>

On Tuesday, 23 September 2025 20:34:00 CEST Kristoffer Haugsbakk wrote:
> Hi
> 
> See the HTML output on e.g. latest `master` (ca2559c1 (The tenth batch,
> 2025-09-18)) for `git-config.adoc`:
> 
>     + For historical reasons, this extension is respected regardless of the
> core.repositoryFormatVersion setting.
> 

At first, I could not see the same output. It seems to be again a discrepancy 
between asciidoc.py and asciidoctor. Only asciidoctor is producing this 
output, and for me, it looks like a bug in asciidoctor.


> The context is a definition item `worktreeConfig` where this is the
> second paragraph following a bullet list.  So I thought maybe you can
> use:
> 
>     --
>     <bullets>
>     --
> 
> Here.  But we’re already inside a `--` block.  So apparently we can’t do
> that.  I also tried a fair amount of permutations of using or not using
> line continuation in this context.
> 
> This particular level of nesting seems tricky to resolve with Asciidoc.
> Maybe someone can figure it out.  So before I forget...
> 
> Thanks
> 
> (The Cc is because he is one of the Asciidoc experts as a FYI only)

Indeed, open blocks cannot be nested [1]. But, the first open block is not 
necessary as it is a workaround for the missing knowledge of multi-level 
definition lists.

[1]: https://docs.asciidoctor.org/asciidoc/latest/blocks/open-blocks/
#:~:text=It%20allows%20you%20to%20apply,inside%20of%20another%20open%20block.

Something along the following lines seems to work with asciidoctor while 
preserving the original paragraph nesting:

diff --git a/Documentation/config/extensions.adoc b/Documentation/config/
extensions.adoc
index 829f2523fc..556eda5d12 100644
--- a/Documentation/config/extensions.adoc
+++ b/Documentation/config/extensions.adoc
@@ -3,8 +3,7 @@ extensions.*::
 	`core.repositoryFormatVersion` is not `1`. See
 	linkgit:gitrepository-layout[5].
 +
---
-compatObjectFormat::
+compatObjectFormat:::
 	Specify a compatibility hash algorithm to use.  The acceptable 
values
 	are `sha1` and `sha256`.  The value specified must be different from 
the
 	value of `extensions.objectFormat`.  This allows client level
@@ -19,18 +18,18 @@ Note that the functionality enabled by this extension is 
incomplete and subject
 to change.  It currently exists only to allow development and testing of
 the underlying feature and is not designed to be enabled by end users.
 
-noop::
+noop:::
 	This extension does not change git's behavior at all. It is useful 
only
 	for testing format-1 compatibility.
 +
 For historical reasons, this extension is respected regardless of the
 `core.repositoryFormatVersion` setting.
 
-noop-v1::
+noop-v1:::
 	This extension does not change git's behavior at all. It is useful 
only
 	for testing format-1 compatibility.
 
-objectFormat::
+objectFormat:::
 	Specify the hash algorithm to use.  The acceptable values are 
`sha1` and
 	`sha256`.  If not specified, `sha1` is assumed.
 +
@@ -38,7 +37,7 @@ Note that this setting should only be set by linkgit:git-
init[1] or
 linkgit:git-clone[1].  Trying to change it after initialization will not
 work and will produce hard-to-diagnose issues.
 
-partialClone::
+partialClone:::
 	When enabled, indicates that the repo was created with a partial 
clone
 	(or later performed a partial fetch) and that the remote may have
 	omitted sending certain unwanted objects.  Such a remote is called 
a
@@ -50,14 +49,14 @@ The value of this key is the name of the promisor remote.
 For historical reasons, this extension is respected regardless of the
 `core.repositoryFormatVersion` setting.
 
-preciousObjects::
+preciousObjects:::
 	If enabled, indicates that objects in the repository MUST NOT be 
deleted
 	(e.g., by `git-prune` or `git repack -d`).
 +
 For historical reasons, this extension is respected regardless of the
 `core.repositoryFormatVersion` setting.
 
-refStorage::
+refStorage:::
 	Specify the ref storage format to use. The acceptable values are:
 +
 include::../ref-storage-format.adoc[]
@@ -67,13 +66,13 @@ Note that this setting should only be set by linkgit:git-
init[1] or
 linkgit:git-clone[1]. Trying to change it after initialization will not
 work and will produce hard-to-diagnose issues.
 
-relativeWorktrees::
+relativeWorktrees:::
 	If enabled, indicates at least one worktree has been linked with
 	relative paths. Automatically set if a worktree has been created or
 	repaired with either the `--relative-paths` option or with the
 	`worktree.useRelativePaths` config set to `true`.
 
-worktreeConfig::
+worktreeConfig:::
 	If enabled, then worktrees will load config settings from the
 	`$GIT_DIR/config.worktree` file in addition to the
 	`$GIT_COMMON_DIR/config` file. Note that `$GIT_COMMON_DIR` and
@@ -87,11 +86,12 @@ When enabling this extension, you must be careful to move
 certain values from the common config file to the main working tree's
 `config.worktree` file, if present:
 +
+--
 * `core.worktree` must be moved from `$GIT_COMMON_DIR/config` to
   `$GIT_COMMON_DIR/config.worktree`.
 * If `core.bare` is true, then it must be moved from `$GIT_COMMON_DIR/config`
   to `$GIT_COMMON_DIR/config.worktree`.
-
+--
 +
 It may also be beneficial to adjust the locations of `core.sparseCheckout`
 and `core.sparseCheckoutCone` depending on your desire for customizable
@@ -104,4 +104,3 @@ details.
 +
 For historical reasons, this extension is respected regardless of the
 `core.repositoryFormatVersion` setting.
---




  reply	other threads:[~2025-09-23 21:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-23 18:34 doc: config/extensions.adoc: line continuation syntax error Kristoffer Haugsbakk
2025-09-23 21:08 ` Jean-Noël AVILA [this message]
2025-09-24  0:54   ` Jeff King
2025-09-26 19:40     ` [PATCH] doc: change the markup of paragraphs following a nested list item Jean-Noël Avila
2025-09-26 20:54       ` Junio C Hamano
2025-09-27 19:39         ` [PATCH v2] " Jean-Noël Avila
2025-09-28 15:35           ` Junio C Hamano
2025-10-03  3:11           ` Jeff King
2025-10-03  3:41             ` Jeff King
2025-10-03 16:29               ` Junio C Hamano
2025-10-04 17:31               ` Jean-Noël AVILA
2025-10-10 16:11                 ` Junio C Hamano
2025-10-10 22:23                   ` Jeff King
2025-10-13 15:17                     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6196161.lOV4Wx5bFT@cayenne \
    --to=jn.avila@free.fr \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).