git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Jean-Noël Avila" <jn.avila@free.fr>
Cc: Jeff King <peff@peff.net>,
	 git@vger.kernel.org,
	 Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: [PATCH] doc: change the markup of paragraphs following a nested list item
Date: Fri, 26 Sep 2025 13:54:10 -0700	[thread overview]
Message-ID: <xmqq5xd5aqa5.fsf@gitster.g> (raw)
In-Reply-To: <20250926194022.19585-1-jn.avila@free.fr> ("Jean-Noël Avila"'s message of "Fri, 26 Sep 2025 21:40:22 +0200")

Jean-Noël Avila <jn.avila@free.fr> writes:

> Asciidoctor and asciidoc.py have different behaviors when a paragraph
> follows a nested list item. Asciidoctor has a bug[1] that makes it add a
> straight plus sign (+) at the beginning of the paragraph.
>
> [1]:https://github.com/asciidoctor/asciidoctor/issues/4704

I read both the above introductory paragraph and the Asciidoctor
issue, but couldn't figure out what a "straight plus sign" is.  Even
if it were a typo of "stray plus sign" (which I am guessing but with
very low confidence), I do not see it at

  https://git.github.io/htmldocs/git-config.html#:~:text=extensions.*,compatObjectFormat

which I think is rendered via Asciidoctor.

Could you rephrase to clarify?

Thanks.


> 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.
> ---
> diff --git a/Documentation/pretty-formats.adoc b/Documentation/pretty-formats.adoc
> index 618ddc4a0c..2121e8e1df 100644
> --- a/Documentation/pretty-formats.adoc
> +++ b/Documentation/pretty-formats.adoc
> @@ -232,7 +232,7 @@ ref names with custom decorations. The `decorate` string may be followed by a
>  colon and zero or more comma-separated options. Option values may contain
>  literal formatting codes. These must be used for commas (`%x2C`) and closing
>  parentheses (`%x29`), due to their role in the option syntax.
> -+
> +
>  ** `prefix=<value>`: Shown before the list of ref names.  Defaults to "{nbsp}++(++".
>  ** `suffix=<value>`: Shown after the list of ref names.  Defaults to "+)+".
>  ** `separator=<value>`: Shown between ref names.  Defaults to "+,+{nbsp}".
> @@ -241,10 +241,12 @@ parentheses (`%x29`), due to their role in the option syntax.
>  ** `tag=<value>`: Shown before tag names. Defaults to "`tag:`{nbsp}".
>  
>  +
> +--
>  For example, to produce decorations with no wrapping
>  or tag annotations, and spaces as separators:
> -+
> +
>  ++%(decorate:prefix=,suffix=,tag=,separator= )++
> +--
>  
>  ++%(describe++`[:<option>,...]`++)++::
>  human-readable name, like linkgit:git-describe[1]; empty string for

  reply	other threads:[~2025-09-26 20:54 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
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 [this message]
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=xmqq5xd5aqa5.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=jn.avila@free.fr \
    --cc=peff@peff.net \
    /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).