* [PATCH 1/4] doc: convert git-imap-send synopsis and options to new style
2026-07-19 19:54 [PATCH 0/4] A new batch of synopsis conversion Jean-Noël Avila via GitGitGadget
@ 2026-07-19 19:54 ` Jean-Noël Avila via GitGitGadget
2026-07-19 19:54 ` [PATCH 2/4] doc: convert git-format-patch " Jean-Noël Avila via GitGitGadget
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Jean-Noël Avila via GitGitGadget @ 2026-07-19 19:54 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila, Jean-Noël Avila
From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
Convert git-imap-send from [verse]/single-quote style to the modern
synopsis-block style:
- Replace [verse] with [synopsis] in SYNOPSIS block
- Backtick-quote all OPTIONS terms
- Backtick-quote all config keys in config/imap.adoc
- Backtick-quote bare config key references in prose
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
Documentation/config/imap.adoc | 2 +-
Documentation/git-imap-send.adoc | 7 +++++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/config/imap.adoc b/Documentation/config/imap.adoc
index cb8f5e2700..6b97776bc3 100644
--- a/Documentation/config/imap.adoc
+++ b/Documentation/config/imap.adoc
@@ -41,7 +41,7 @@
`imap.authMethod`::
Specify the authentication method for authenticating with the IMAP server.
If Git was built with the NO_CURL option, or if your curl version is older
- than 7.34.0, or if you're running git-imap-send with the `--no-curl`
+ than 7.34.0, or if you're running `git-imap-send` with the `--no-curl`
option, the only supported methods are `PLAIN`, `CRAM-MD5`, `OAUTHBEARER`
and `XOAUTH2`. If this is not set then `git imap-send` uses the basic IMAP
plaintext `LOGIN` command.
diff --git a/Documentation/git-imap-send.adoc b/Documentation/git-imap-send.adoc
index 538b91afc0..dd1e0a3718 100644
--- a/Documentation/git-imap-send.adoc
+++ b/Documentation/git-imap-send.adoc
@@ -192,7 +192,10 @@ supports only `XOAUTH2` as the mechanism.
Once the commits are ready to be sent, run the following command:
- $ git format-patch --cover-letter -M --stdout origin/master | git imap-send
+
+---------
+$ git format-patch --cover-letter -M --stdout origin/master | git imap-send
+---------
Just make sure to disable line wrapping in the email client (Gmail's web
interface will wrap lines no matter what, so you need to use a real
@@ -217,7 +220,7 @@ users may wish to visit this web page for more information:
SEE ALSO
--------
-linkgit:git-format-patch[1], linkgit:git-send-email[1], mbox(5)
+linkgit:git-format-patch[1], linkgit:git-send-email[1], `mbox`(5)
GIT
---
--
gitgitgadget
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH 2/4] doc: convert git-format-patch synopsis and options to new style
2026-07-19 19:54 [PATCH 0/4] A new batch of synopsis conversion Jean-Noël Avila via GitGitGadget
2026-07-19 19:54 ` [PATCH 1/4] doc: convert git-imap-send synopsis and options to new style Jean-Noël Avila via GitGitGadget
@ 2026-07-19 19:54 ` Jean-Noël Avila via GitGitGadget
2026-07-19 23:40 ` Junio C Hamano
2026-07-19 19:54 ` [PATCH 3/4] doc: convert git-send-email " Jean-Noël Avila via GitGitGadget
2026-07-19 19:54 ` [PATCH 4/4] doc: convert git-request-pull " Jean-Noël Avila via GitGitGadget
3 siblings, 1 reply; 10+ messages in thread
From: Jean-Noël Avila via GitGitGadget @ 2026-07-19 19:54 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila, Jean-Noël Avila
From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
Replace [verse] with [synopsis] in the SYNOPSIS block and remove
single-quote formatting from the command name.
Backtick-quote all option terms in the OPTIONS section, convert
standalone placeholders to _<placeholder>_ form, and convert
single-quoted commands and tools in prose to backtick form.
Also update the included files:
- diff-options.adoc: backtick-quote the git-format-patch-specific
option terms (-p, --no-stat, --max-depth=<depth>)
- format-patch-caveats.adoc: convert patch(1) to `patch`(1)
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
Documentation/diff-options.adoc | 8 +-
Documentation/git-format-patch.adoc | 264 ++++++++++++++--------------
2 files changed, 136 insertions(+), 136 deletions(-)
diff --git a/Documentation/diff-options.adoc b/Documentation/diff-options.adoc
index c8242e2462..e605d28678 100644
--- a/Documentation/diff-options.adoc
+++ b/Documentation/diff-options.adoc
@@ -13,8 +13,8 @@ endif::git-diff[]
endif::git-format-patch[]
ifdef::git-format-patch[]
--p::
---no-stat::
+`-p`::
+`--no-stat`::
Generate plain patches without any diffstats.
endif::git-format-patch[]
@@ -893,8 +893,8 @@ endif::git-format-patch[]
reverted with `--ita-visible-in-index`. Both options are
experimental and could be removed in future.
---max-depth=<depth>::
- For each pathspec given on command line, descend at most `<depth>`
+`--max-depth=<depth>`::
+ For each pathspec given on command line, descend at most _<depth>_
levels of directories. A value of `-1` means no limit.
Cannot be combined with wildcards in the pathspec.
Given a tree containing `foo/bar/baz`, the following list shows the
diff --git a/Documentation/git-format-patch.adoc b/Documentation/git-format-patch.adoc
index f7905c0f7c..5eccb2cf60 100644
--- a/Documentation/git-format-patch.adoc
+++ b/Documentation/git-format-patch.adoc
@@ -8,8 +8,8 @@ git-format-patch - Prepare patches for e-mail submission
SYNOPSIS
--------
-[verse]
-'git format-patch' [-k] [(-o|--output-directory) <dir> | --stdout]
+[synopsis]
+git format-patch [-k] [(-o|--output-directory) <dir> | --stdout]
[--no-thread | --thread[=<style>]]
[(--attach|--inline)[=<boundary>] | --no-attach]
[-s | --signoff]
@@ -40,20 +40,20 @@ DESCRIPTION
Prepare each non-merge commit with its "patch" in
one "message" per commit, formatted to resemble a UNIX mailbox.
The output of this command is convenient for e-mail submission or
-for use with 'git am'.
+for use with `git am`.
A "message" generated by the command consists of three parts:
* A brief metadata header that begins with `From <commit>`
with a fixed `Mon Sep 17 00:00:00 2001` datestamp to help programs
- like "file(1)" to recognize that the file is an output from this
+ like `file`(1) to recognize that the file is an output from this
command, fields that record the author identity, the author date,
and the title of the change (taken from the first paragraph of the
commit log message).
* The second and subsequent paragraphs of the commit log message.
-* The "patch", which is the "diff -p --stat" output (see
+* The "patch", which is the `diff -p --stat` output (see
linkgit:git-diff[1]) between the commit and its parent.
The log message and the patch are separated by a line with a
@@ -61,18 +61,18 @@ three-dash line.
There are two ways to specify which commits to operate on.
-1. A single commit, <since>, specifies that the commits leading
+1. A single commit, _<since>_, specifies that the commits leading
to the tip of the current branch that are not in the history
- that leads to the <since> to be output.
+ that leads to the _<since>_ to be output.
-2. Generic <revision-range> expression (see "SPECIFYING
- REVISIONS" section in linkgit:gitrevisions[7]) means the
+2. Generic _<revision-range>_ expression (see 'SPECIFYING
+ REVISIONS' section in linkgit:gitrevisions[7]) means the
commits in the specified range.
-The first rule takes precedence in the case of a single <commit>. To
+The first rule takes precedence in the case of a single _<commit>_. To
apply the second rule, i.e., format everything since the beginning of
-history up until <commit>, use the `--root` option: `git format-patch
---root <commit>`. If you want to format only <commit> itself, you
+history up until _<commit>_, use the `--root` option: `git format-patch
+--root <commit>`. If you want to format only _<commit>_ itself, you
can do this with `git format-patch -1 <commit>`.
By default, each output file is numbered sequentially from 1, and uses the
@@ -82,7 +82,7 @@ will only be numbers, without the first line of the commit appended.
The names of the output files are printed to standard
output, unless the `--stdout` option is specified.
-If `-o` is specified, output files are created in <dir>. Otherwise
+If `-o` is specified, output files are created in _<dir>_. Otherwise
they are created in the current working directory. The default path
can be set with the `format.outputDirectory` configuration option.
The `-o` option takes precedence over `format.outputDirectory`.
@@ -108,119 +108,119 @@ OPTIONS
:git-format-patch: 1
include::diff-options.adoc[]
--<n>::
- Prepare patches from the topmost <n> commits.
+`-<n>`::
+ Prepare patches from the topmost _<n>_ commits.
--o <dir>::
---output-directory <dir>::
- Use <dir> to store the resulting files, instead of the
+`-o <dir>`::
+`--output-directory=<dir>`::
+ Use _<dir>_ to store the resulting files, instead of the
current working directory.
--n::
---numbered::
+`-n`::
+`--numbered`::
Name output in '[PATCH n/m]' format, even with a single patch.
--N::
---no-numbered::
+`-N`::
+`--no-numbered`::
Name output in '[PATCH]' format.
---start-number <n>::
- Start numbering the patches at <n> instead of 1.
+`--start-number <n>`::
+ Start numbering the patches at _<n>_ instead of 1.
---numbered-files::
+`--numbered-files`::
Output file names will be a simple number sequence
without the default first line of the commit appended.
--k::
---keep-subject::
+`-k`::
+`--keep-subject`::
Do not strip/add '[PATCH]' from the first line of the
commit log message.
--s::
---signoff::
+`-s`::
+`--signoff`::
Add a `Signed-off-by` trailer to the commit message, using
the committer identity of yourself.
See the signoff option in linkgit:git-commit[1] for more information.
---stdout::
+`--stdout`::
Print all commits to the standard output in mbox format,
instead of creating a file for each one.
---attach[=<boundary>]::
+`--attach[=<boundary>]`::
Create multipart/mixed attachment, the first part of
which is the commit message and the patch itself in the
second part, with `Content-Disposition: attachment`.
---no-attach::
+`--no-attach`::
Disable the creation of an attachment, overriding the
configuration setting.
---inline[=<boundary>]::
+`--inline[=<boundary>]`::
Create multipart/mixed attachment, the first part of
which is the commit message and the patch itself in the
second part, with `Content-Disposition: inline`.
---thread[=<style>]::
---no-thread::
- Controls addition of `In-Reply-To` and `References` headers to
+`--thread[=<style>]`::
+`--no-thread`::
+ Control addition of `In-Reply-To` and `References` headers to
make the second and subsequent mails appear as replies to the
first. Also controls generation of the `Message-ID` header to
reference.
+
-The optional <style> argument can be either `shallow` or `deep`.
-'shallow' threading makes every mail a reply to the head of the
+The optional _<style>_ argument can be either `shallow` or `deep`.
+`shallow` threading makes every mail a reply to the head of the
series, where the head is chosen from the cover letter, the
-`--in-reply-to`, and the first patch mail, in this order. 'deep'
+`--in-reply-to`, and the first patch mail, in this order. `deep`
threading makes every mail a reply to the previous one.
+
The default is `--no-thread`, unless the `format.thread` configuration
is set. `--thread` without an argument is equivalent to `--thread=shallow`.
+
-Beware that the default for 'git send-email' is to thread emails
+Beware that the default for `git send-email` is to thread emails
itself. If you want `git format-patch` to take care of threading, you
will want to ensure that threading is disabled for `git send-email`.
---in-reply-to=<message-id>::
+`--in-reply-to=<message-id>`::
Make the first mail (or all the mails with `--no-thread`) appear as a
- reply to the given <message-id>, which avoids breaking threads to
+ reply to the given _<message-id>_, which avoids breaking threads to
provide a new patch series.
---ignore-if-in-upstream::
+`--ignore-if-in-upstream`::
Do not include a patch that matches a commit in
- <until>..<since>. This will examine all patches reachable
- from <since> but not from <until> and compare them with the
+ _<until>_.._<since>_. This will examine all patches reachable
+ from _<since>_ but not from _<until>_ and compare them with the
patches being generated, and any patch that matches is
ignored.
---always::
+`--always`::
Include patches for commits that do not introduce any change,
which are omitted by default.
---cover-from-description=<mode>::
- Controls which parts of the cover letter will be automatically
+`--cover-from-description=<mode>`::
+ Control which parts of the cover letter will be automatically
populated using the branch's description.
+
-If `<mode>` is `message` or `default`, the cover letter subject will be
+_<mode>_ can have the following values:
+
+`message`;;
+`default`;; the cover letter subject will be
populated with placeholder text. The body of the cover letter will be
populated with the branch's description. This is the default mode when
no configuration nor command line option is specified.
-+
-If `<mode>` is `subject`, the first paragraph of the branch description will
+`subject`;; the first paragraph of the branch description will
populate the cover letter subject. The remainder of the description will
populate the body of the cover letter.
-+
-If `<mode>` is `auto`, if the first paragraph of the branch description
+`auto`;; if the first paragraph of the branch description
is greater than 100 bytes, then the mode will be `message`, otherwise
`subject` will be used.
-+
-If `<mode>` is `none`, both the cover letter subject and body will be
+`none`;; both the cover letter subject and body will be
populated with placeholder text.
---description-file=<file>::
- Use the contents of <file> instead of the branch's description
+`--description-file=<file>`::
+ Use the contents of _<file>_ instead of the branch's description
for generating the cover letter.
---subject-prefix=<subject-prefix>::
+`--subject-prefix=<subject-prefix>`::
Use '[<subject-prefix>]' instead of the standard '[PATCH]'
prefix in the subject line. This can be used to name a patch
series, and can be combined with the `--numbered` option.
@@ -231,14 +231,14 @@ all patches. This is often useful on mailing lists which receive
patches for several repositories and can be used to disambiguate
the patches (with a value of e.g. "PATCH my-project").
---filename-max-length=<n>::
+`--filename-max-length=<n>`::
Instead of the standard 64 bytes, chomp the generated output
- filenames at around '<n>' bytes (too short a value will be
+ filenames at around _<n>_ bytes (too short a value will be
silently raised to a reasonable length). Defaults to the
value of the `format.filenameMaxLength` configuration
variable, or 64 if unconfigured.
---rfc[=<rfc>]::
+`--rfc[=<rfc>]`::
Prepends the string _<rfc>_ (defaults to "RFC") to
the subject prefix. As the subject prefix defaults to
"PATCH", you'll get "RFC PATCH" by default.
@@ -254,38 +254,38 @@ can be prefixed with a dash ("`-`") to signal that the rest of
the _<rfc>_ string should be appended to the subject prefix instead,
e.g., `--rfc='-(WIP)'` results in "PATCH (WIP)".
--v <n>::
---reroll-count=<n>::
- Mark the series as the <n>-th iteration of the topic. The
+`-v <n>`::
+`--reroll-count=<n>`::
+ Mark the series as the _<n>_-th iteration of the topic. The
output filenames have `v<n>` prepended to them, and the
subject prefix ("PATCH" by default, but configurable via the
- `--subject-prefix` option) has ` v<n>` appended to it. E.g.
+ `--subject-prefix` option) has `v<n>` appended to it. E.g.
`--reroll-count=4` may produce `v4-0001-add-makefile.patch`
file that has "Subject: [PATCH v4 1/20] Add makefile" in it.
- `<n>` does not have to be an integer (e.g. "--reroll-count=4.4",
- or "--reroll-count=4rev2" are allowed), but the downside of
+ _<n>_ does not have to be an integer (e.g. `--reroll-count=4.4`,
+ or `--reroll-count=4rev2` are allowed), but the downside of
using such a reroll-count is that the range-diff/interdiff
with the previous version does not state exactly which
version the new iteration is compared against.
---to=<email>::
+`--to=<email>`::
Add a `To:` header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
The negated form `--no-to` discards all `To:` headers added so
far (from config or command line).
---cc=<email>::
+`--cc=<email>`::
Add a `Cc:` header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
The negated form `--no-cc` discards all `Cc:` headers added so
far (from config or command line).
---from::
---from=<ident>::
- Use `ident` in the `From:` header of each email. In case of a
+`--from`::
+`--from=<ident>`::
+ Use _<ident>_ in the `From:` header of each email. In case of a
commit email, if the author ident of the commit is not textually
- identical to the provided `ident`, place a `From:` header in the
- body of the message with the original author. If no `ident` is
+ identical to the provided _<ident>_, place a `From:` header in the
+ body of the message with the original author. If no _<ident>_ is
given, or if the option is not passed at all, use the ident of
the current committer.
+
@@ -296,8 +296,8 @@ header). Note also that `git send-email` already handles this
transformation for you, and this option should not be used if you are
feeding the result to `git send-email`.
---force-in-body-from::
---no-force-in-body-from::
+`--force-in-body-from`::
+`--no-force-in-body-from`::
With the e-mail sender specified via the `--from` option, by
default, an in-body "From:" to identify the real author of
the commit is added at the top of the commit log message if
@@ -308,7 +308,7 @@ feeding the result to `git send-email`.
Defaults to the value of the `format.forceInBodyFrom`
configuration variable.
---add-header=<header>::
+`--add-header=<header>`::
Add an arbitrary header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
For example, `--add-header="Organization: git-foo"`.
@@ -316,13 +316,13 @@ feeding the result to `git send-email`.
`Cc:`, and custom) headers added so far from config or command
line.
---cover-letter::
---no-cover-letter::
+`--cover-letter`::
+`--no-cover-letter`::
In addition to the patches, generate a cover letter file containing the
branch description, commit list and the overall diffstat. You can fill
in a description in the file before sending it out.
---commit-list-format=<format-spec>::
+`--commit-list-format=<format-spec>`::
Specify the format in which to generate the commit list of the patch
series. The accepted values for format-spec are `shortlog`, `modern` or
a format-string prefixed with `log:`. E.g. `log: %s (%an)`.
@@ -334,28 +334,28 @@ feeding the result to `git send-email`.
This option given from the command-line implies the use of
`--cover-letter` unless `--no-cover-letter` is given.
---encode-email-headers::
---no-encode-email-headers::
+`--encode-email-headers`::
+`--no-encode-email-headers`::
Encode email headers that have non-ASCII characters with
"Q-encoding" (described in RFC 2047), instead of outputting the
headers verbatim. Defaults to the value of the
`format.encodeEmailHeaders` configuration variable.
---interdiff=<previous>::
+`--interdiff=<previous>`::
As a reviewer aid, insert an interdiff into the cover letter,
or as commentary of the lone patch of a 1-patch series, showing
the differences between the previous version of the patch series and
- the series currently being formatted. `previous` is a single revision
+ the series currently being formatted. _<previous>_ is a single revision
naming the tip of the previous series which shares a common base with
the series being formatted (for example `git format-patch
--cover-letter --interdiff=feature/v1 -3 feature/v2`).
---range-diff=<previous>::
+`--range-diff=<previous>`::
As a reviewer aid, insert a range-diff (see linkgit:git-range-diff[1])
into the cover letter, or as commentary of the lone patch of a
1-patch series, showing the differences between the previous
version of the patch series and the series currently being formatted.
- `previous` can be a single revision naming the tip of the previous
+ _<previous>_ can be a single revision naming the tip of the previous
series if it shares a common base with the series being formatted (for
example `git format-patch --cover-letter --range-diff=feature/v1 -3
feature/v2`), or a revision range if the two versions of the series are
@@ -367,7 +367,7 @@ product of `format-patch` is generated, and they are not passed to
the underlying `range-diff` machinery used to generate the cover-letter
material (this may change in the future).
---creation-factor=<percent>::
+`--creation-factor=<percent>`::
Used with `--range-diff`, tweak the heuristic which matches up commits
between the previous and current series of patches by adjusting the
creation/deletion cost fudge factor. See linkgit:git-range-diff[1])
@@ -378,8 +378,8 @@ case is to show comparison with an older iteration of the same
topic and the tool should find more correspondence between the two
sets of patches.
---notes[=<ref>]::
---no-notes::
+`--notes[=<ref>]`::
+`--no-notes`::
Append the notes (see linkgit:git-notes[1]) for the commit
after the three-dash line.
+
@@ -394,17 +394,17 @@ configuration options in linkgit:git-notes[1] to use this workflow).
The default is `--no-notes`, unless the `format.notes` configuration is
set.
---signature=<signature>::
---no-signature::
+`--signature=<signature>`::
+`--no-signature`::
Add a signature to each message produced. Per RFC 3676 the signature
- is separated from the body by a line with '-- ' on it. If the
+ is separated from the body by a line with "-- " on it. If the
signature option is omitted the signature defaults to the Git version
number.
---signature-file=<file>::
- Works just like --signature except the signature is read from a file.
+`--signature-file=<file>`::
+ Works just like `--signature` except the signature is read from a file.
---suffix=.<sfx>::
+`--suffix=.<sfx>`::
Instead of using `.patch` as the suffix for generated
filenames, use specified suffix. A common alternative is
`--suffix=.txt`. Leaving this empty will remove the `.patch`
@@ -413,36 +413,36 @@ set.
Note that the leading character does not have to be a dot; for example,
you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
--q::
---quiet::
+`-q`::
+`--quiet`::
Do not print the names of the generated files to standard output.
---no-binary::
+`--no-binary`::
Do not output contents of changes in binary files, instead
display a notice that those files changed. Patches generated
using this option cannot be applied properly, but they are
still useful for code review.
---zero-commit::
+`--zero-commit`::
Output an all-zero hash in each patch's From header instead
of the hash of the commit.
---no-base::
---base[=<commit>]::
+`--no-base`::
+`--base[=<commit>]`::
Record the base tree information to identify the state the
patch series applies to. See the BASE TREE INFORMATION section
- below for details. If <commit> is "auto", a base commit is
+ below for details. If _<commit>_ is `auto`, a base commit is
automatically chosen. The `--no-base` option overrides a
`format.useAutoBase` configuration.
---root::
- Treat the revision argument as a <revision-range>, even if it
+`--root`::
+ Treat the revision argument as a _<revision-range>_, even if it
is just a single commit (that would normally be treated as a
- <since>). Note that root commits included in the specified
+ _<since>_). Note that root commits included in the specified
range are always formatted as creation patches, independently
of this flag.
---progress::
+`--progress`::
Show progress reports on stderr as patches are generated.
CONFIGURATION
@@ -473,7 +473,7 @@ with configuration variables.
DISCUSSION
----------
-The patch produced by 'git format-patch' is in UNIX mailbox format,
+The patch produced by `git format-patch` is in UNIX mailbox format,
with a fixed "magic" time stamp to indicate that the file is output
from format-patch rather than a real mailbox, like so:
@@ -502,8 +502,8 @@ can save interesting patches in a UNIX mailbox and apply them with
linkgit:git-am[1].
When a patch is part of an ongoing discussion, the patch generated by
-'git format-patch' can be tweaked to take advantage of the 'git am
---scissors' feature. After your response to the discussion comes a
+`git format-patch` can be tweaked to take advantage of the `git am
+--scissors` feature. After your response to the discussion comes a
line that consists solely of "`-- >8 --`" (scissors and perforation),
followed by the patch with unnecessary header fields removed:
@@ -540,7 +540,7 @@ two common types of corruption:
One way to test if your MUA is set up correctly is:
* Send the patch to yourself, exactly the way you would, except
- with To: and Cc: lines that do not contain the list and
+ with `To:` and `Cc:` lines that do not contain the list and
maintainer address.
* Save that patch to a file in UNIX mailbox format. Call it a.patch,
@@ -561,12 +561,12 @@ If it does not apply correctly, there can be various reasons.
this case.
* The MUA corrupted your patch; "am" would complain that
- the patch does not apply. Look in the .git/rebase-apply/ subdirectory and
- see what 'patch' file contains and check for the common
- corruption patterns mentioned above.
+ the patch does not apply. Look in the `.git/rebase-apply/` subdirectory and
+ see what `patch` file contains and check for the common
+ corruption patterns mentioned above.
-* While at it, check the 'info' and 'final-commit' files as well.
- If what is in 'final-commit' is not exactly what you would want to
+* While at it, check the `info` and `final-commit` files as well.
+ If what is in `final-commit` is not exactly what you would want to
see in the commit log message, it is very likely that the
receiver would end up hand editing the log message when applying
your patch. Things like "Hi, this is my first patch.\n" in the
@@ -582,11 +582,11 @@ GMail
~~~~~
GMail does not have any way to turn off line wrapping in the web
interface, so it will mangle any emails that you send. You can however
-use "git send-email" and send your patches through the GMail SMTP server, or
+use `git send-email` and send your patches through the GMail SMTP server, or
use any IMAP email client to connect to the google IMAP server and forward
the emails through that.
-For hints on using 'git send-email' to send your patches through the
+For hints on using `git send-email` to send your patches through the
GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1].
For hints on submission using the IMAP interface, see the EXAMPLE
@@ -595,7 +595,7 @@ section of linkgit:git-imap-send[1].
Thunderbird
~~~~~~~~~~~
By default, Thunderbird will both wrap emails as well as flag
-them as being 'format=flowed', both of which will make the
+them as being `format=flowed`, both of which will make the
resulting email unusable by Git.
There are three different approaches: use an add-on to turn off line wraps,
@@ -609,14 +609,14 @@ Install the Toggle Line Wrap add-on that is available from
https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
It adds a button "Line Wrap" to the composer's toolbar
that you can tick off. Now you can compose the message as you otherwise do
-(cut + paste, 'git format-patch' | 'git imap-send', etc), but you have to
+(cut + paste, `git format-patch` | `git imap-send`, etc), but you have to
insert line breaks manually in any text that you type.
As a bonus feature, the add-on can detect patch text in the composer
and warns when line wrapping has not yet been turned off.
The add-on requires a few tweaks of the advanced configuration
-(about:config). These are listed on the download page.
+(`about:config`). These are listed on the download page.
Approach #2 (configuration)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -643,7 +643,7 @@ Toggle it to make sure it is set to `false`. Also, search for
Toggle it to make sure it is set to `false`.
After that is done, you should be able to compose email as you
-otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),
+otherwise would (cut + paste, `git format-patch` | `git imap-send`, etc),
and the patches will not be mangled.
Approach #3 (external editor)
@@ -660,7 +660,7 @@ External Editor from https://globs.org/articles.php?lng=en&pg=8
"Composition & Addressing" panel of the account to be used to
send the patch.
-3. In the main Thunderbird window, 'before' you open the compose
+3. In the main Thunderbird window, _before_ you open the compose
window for the patch, use Tools->about:config to set the
following to the indicated values:
+
@@ -708,15 +708,15 @@ BASE TREE INFORMATION
The base tree information block is used for maintainers or third party
testers to know the exact state the patch series applies to. It consists
-of the 'base commit', which is a well-known commit that is part of the
+of the "base commit", which is a well-known commit that is part of the
stable part of the project history everybody else works off of, and zero
-or more 'prerequisite patches', which are well-known patches in flight
-that is not yet part of the 'base commit' that need to be applied on top
-of 'base commit' in topological order before the patches can be applied.
+or more "prerequisite patches", which are well-known patches in flight
+that is not yet part of the "base commit" that need to be applied on top
+of "base commit" in topological order before the patches can be applied.
-The 'base commit' is shown as "base-commit: " followed by the 40-hex of
-the commit object name. A 'prerequisite patch' is shown as
-"prerequisite-patch-id: " followed by the 40-hex 'patch id', which can
+The "base commit" is shown as "base-commit: " followed by the 40-hex of
+the commit object name. A `prerequisite patch` is shown as
+"prerequisite-patch-id: " followed by the 40-hex `patch id`, which can
be obtained by passing the patch through the `git patch-id --stable`
command.
@@ -763,7 +763,7 @@ EXAMPLES
--------
* Extract commits between revisions R1 and R2, and apply them on top of
- the current branch using 'git am' to cherry-pick them:
+ the current branch using `git am` to cherry-pick them:
+
------------
$ git format-patch -k --stdout R1..R2 | git am -3 -k
@@ -778,7 +778,7 @@ $ git format-patch origin
+
For each commit a separate file is created in the current directory.
-* Extract all commits that lead to 'origin' since the inception of the
+* Extract all commits that lead to `origin` since the inception of the
project:
+
------------
@@ -794,7 +794,7 @@ $ git format-patch -M -B origin
Additionally, it detects and handles renames and complete rewrites
intelligently to produce a renaming patch. A renaming patch reduces
the amount of text output, and generally makes it easier to review.
-Note that non-Git "patch" programs won't understand renaming patches, so
+Note that non-Git `patch` programs won't understand renaming patches, so
use it only when you know the recipient uses Git to apply your patch.
* Extract three topmost commits from the current branch and format them
--
gitgitgadget
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH 2/4] doc: convert git-format-patch synopsis and options to new style
2026-07-19 19:54 ` [PATCH 2/4] doc: convert git-format-patch " Jean-Noël Avila via GitGitGadget
@ 2026-07-19 23:40 ` Junio C Hamano
2026-07-20 20:09 ` Jean-Noël AVILA
0 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2026-07-19 23:40 UTC (permalink / raw)
To: Jean-Noël Avila via GitGitGadget; +Cc: git, Jean-Noël Avila
"Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Backtick-quote all option terms in the OPTIONS section, convert
> standalone placeholders to _<placeholder>_ form, and convert
> single-quoted commands and tools in prose to backtick form.
OK.
> @@ -708,15 +708,15 @@ BASE TREE INFORMATION
>
> The base tree information block is used for maintainers or third party
> testers to know the exact state the patch series applies to. It consists
> +of the "base commit", which is a well-known commit that is part of the
> stable part of the project history everybody else works off of, and zero
> +or more "prerequisite patches", which are well-known patches in flight
> +that is not yet part of the "base commit" that need to be applied on top
> +of "base commit" in topological order before the patches can be applied.
GIven that the last part of this hunk below uses backtick-quoting
for `prerequisite patch` and `patch id`, shouldn't the references to
`base commit`, and `prerequisite patch(es)` in the above also be
backtick quoted for consistency?
> +The "base commit" is shown as "base-commit: " followed by the 40-hex of
> +the commit object name. A `prerequisite patch` is shown as
> +"prerequisite-patch-id: " followed by the 40-hex `patch id`, which can
> be obtained by passing the patch through the `git patch-id --stable`
> command.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/4] doc: convert git-format-patch synopsis and options to new style
2026-07-19 23:40 ` Junio C Hamano
@ 2026-07-20 20:09 ` Jean-Noël AVILA
0 siblings, 0 replies; 10+ messages in thread
From: Jean-Noël AVILA @ 2026-07-20 20:09 UTC (permalink / raw)
To: Jean-Noël Avila via GitGitGadget, Junio C Hamano; +Cc: git
On Monday, 20 July 2026 01:40:17 CEST Junio C Hamano wrote:
> "Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > Backtick-quote all option terms in the OPTIONS section, convert
> > standalone placeholders to _<placeholder>_ form, and convert
> > single-quoted commands and tools in prose to backtick form.
>
> OK.
>
> > @@ -708,15 +708,15 @@ BASE TREE INFORMATION
> >
> > The base tree information block is used for maintainers or third party
> > testers to know the exact state the patch series applies to. It consists
> >
> > +of the "base commit", which is a well-known commit that is part of the
> >
> > stable part of the project history everybody else works off of, and zero
> >
> > +or more "prerequisite patches", which are well-known patches in flight
> > +that is not yet part of the "base commit" that need to be applied on top
> > +of "base commit" in topological order before the patches can be applied.
>
> GIven that the last part of this hunk below uses backtick-quoting
> for `prerequisite patch` and `patch id`, shouldn't the references to
> `base commit`, and `prerequisite patch(es)` in the above also be
> backtick quoted for consistency?
>
In fact, the formatting were swapped. For proper rendering and preservation of
spaces, it should be:
The "base commit" is shown as "`base-commit:` " followed by the 40-hex of
the commit object name. A "prerequisite patch" is shown as
"`prerequisite-patch-id:` " followed by the 40-hex "patch id", which can
be obtained by passing the patch through the `git patch-id --stable`
command.
Only the constant strings are back-ticked. The others are only quoted.
Will reroll.
> > +The "base commit" is shown as "base-commit: " followed by the 40-hex of
> > +the commit object name. A `prerequisite patch` is shown as
> > +"prerequisite-patch-id: " followed by the 40-hex `patch id`, which can
> >
> > be obtained by passing the patch through the `git patch-id --stable`
> > command.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 3/4] doc: convert git-send-email synopsis and options to new style
2026-07-19 19:54 [PATCH 0/4] A new batch of synopsis conversion Jean-Noël Avila via GitGitGadget
2026-07-19 19:54 ` [PATCH 1/4] doc: convert git-imap-send synopsis and options to new style Jean-Noël Avila via GitGitGadget
2026-07-19 19:54 ` [PATCH 2/4] doc: convert git-format-patch " Jean-Noël Avila via GitGitGadget
@ 2026-07-19 19:54 ` Jean-Noël Avila via GitGitGadget
2026-07-19 19:54 ` [PATCH 4/4] doc: convert git-request-pull " Jean-Noël Avila via GitGitGadget
3 siblings, 0 replies; 10+ messages in thread
From: Jean-Noël Avila via GitGitGadget @ 2026-07-19 19:54 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila, Jean-Noël Avila
From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
Replace [verse] with [synopsis] in the SYNOPSIS block and remove
single-quote formatting from the command name.
Backtick-quote all option terms in the OPTIONS section, convert
the standalone placeholder _<encoding>_ in prose, fix single-quoted
server names to backtick form, and convert mbox(5) to `mbox`(5).
Also update config/sendemail.adoc: backtick-quote all configuration
key terms and fix a bare sendemail.aliasesFile reference in prose.
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
Documentation/config/sendemail.adoc | 92 ++++++++--------
Documentation/git-send-email.adoc | 162 ++++++++++++++--------------
2 files changed, 127 insertions(+), 127 deletions(-)
diff --git a/Documentation/config/sendemail.adoc b/Documentation/config/sendemail.adoc
index 1d700559b4..5499f91036 100644
--- a/Documentation/config/sendemail.adoc
+++ b/Documentation/config/sendemail.adoc
@@ -1,25 +1,25 @@
-sendemail.identity::
+`sendemail.identity`::
A configuration identity. When given, causes values in the
`sendemail.<identity>` subsection to take precedence over
values in the `sendemail` section. The default identity is
the value of `sendemail.identity`.
-sendemail.smtpEncryption::
+`sendemail.smtpEncryption`::
See linkgit:git-send-email[1] for description. Note that this
setting is not subject to the `identity` mechanism.
-sendemail.smtpSSLCertPath::
+`sendemail.smtpSSLCertPath`::
Path to ca-certificates (either a directory or a single file).
Set it to an empty string to disable certificate verification.
-sendemail.smtpSSLClientCert::
+`sendemail.smtpSSLClientCert`::
Path to the client certificate file to present if requested by the
server. This is required when the server is set up to verify client
certificates. If the corresponding private key is not included in the
file, it must be supplied using `sendemail.smtpSSLClientKey` or the
`--smtp-ssl-client-key` option.
-sendemail.smtpSSLClientKey::
+`sendemail.smtpSSLClientKey`::
Path to the client private key file that corresponds to the client
certificate. To avoid misconfiguration, this configuration must be used
in conjunction with `sendemail.smtpSSLClientCert` or the
@@ -28,45 +28,45 @@ sendemail.smtpSSLClientKey::
the certificate. Visit https://metacpan.org/pod/IO::Socket::SSL for more
details.
-sendemail.<identity>.*::
- Identity-specific versions of the `sendemail.*` parameters
+`sendemail.<identity>.<config>`::
+ Identity-specific versions of the `sendemail.<config>` parameters
found below, taking precedence over those when this
identity is selected, through either the command-line or
`sendemail.identity`.
-sendemail.multiEdit::
+`sendemail.multiEdit`::
If `true` (default), a single editor instance will be spawned to edit
files you have to edit (patches when `--annotate` is used, and the
summary when `--compose` is used). If `false`, files will be edited one
after the other, spawning a new editor each time.
-sendemail.confirm::
+`sendemail.confirm`::
Sets the default for whether to confirm before sending. Must be
one of `always`, `never`, `cc`, `compose`, or `auto`. See `--confirm`
in the linkgit:git-send-email[1] documentation for the meaning of these
values.
-sendemail.mailmap::
+`sendemail.mailmap`::
If `true`, makes linkgit:git-send-email[1] assume `--mailmap`,
otherwise assume `--no-mailmap`. `False` by default.
-sendemail.mailmap.file::
+`sendemail.mailmap.file`::
The location of a linkgit:git-send-email[1] specific augmenting
mailmap file. The default mailmap and `mailmap.file` are loaded
first. Thus, entries in this file take precedence over entries in
the default mailmap locations. See linkgit:gitmailmap[5].
-sendemail.mailmap.blob::
+`sendemail.mailmap.blob`::
Like `sendemail.mailmap.file`, but consider the value as a reference
to a blob in the repository. Entries in `sendemail.mailmap.file`
take precedence over entries here. See linkgit:gitmailmap[5].
-sendemail.aliasesFile::
+`sendemail.aliasesFile`::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply `sendemail.aliasFileType`.
-sendemail.aliasFileType::
- Format of the file(s) specified in sendemail.aliasesFile. Must be
+`sendemail.aliasFileType`::
+ Format of the file(s) specified in `sendemail.aliasesFile`. Must be
one of `mutt`, `mailrc`, `pine`, `elm`, `gnus`, or `sendmail`.
+
What an alias file in each format looks like can be found in
@@ -75,7 +75,7 @@ differences and limitations from the standard formats are
described below:
+
--
-sendmail;;
+`sendmail`;;
* Quoted aliases and quoted addresses are not supported: lines that
contain a `"` symbol are ignored.
* Redirection to a file (`/path/name`) or pipe (`|command`) is not
@@ -85,54 +85,54 @@ sendmail;;
explicitly unsupported constructs, and any other lines that are not
recognized by the parser.
--
-sendemail.annotate::
-sendemail.bcc::
-sendemail.cc::
-sendemail.ccCmd::
-sendemail.chainReplyTo::
-sendemail.envelopeSender::
-sendemail.from::
-sendemail.headerCmd::
-sendemail.signedOffByCc::
-sendemail.smtpPass::
-sendemail.suppressCc::
-sendemail.suppressFrom::
-sendemail.to::
-sendemail.toCmd::
-sendemail.smtpDomain::
-sendemail.smtpServer::
-sendemail.smtpServerPort::
-sendemail.smtpServerOption::
-sendemail.smtpUser::
-sendemail.imapSentFolder::
-sendemail.useImapOnly::
-sendemail.thread::
-sendemail.transferEncoding::
-sendemail.validate::
-sendemail.xmailer::
+`sendemail.annotate`::
+`sendemail.bcc`::
+`sendemail.cc`::
+`sendemail.ccCmd`::
+`sendemail.chainReplyTo`::
+`sendemail.envelopeSender`::
+`sendemail.from`::
+`sendemail.headerCmd`::
+`sendemail.signedOffByCc`::
+`sendemail.smtpPass`::
+`sendemail.suppressCc`::
+`sendemail.suppressFrom`::
+`sendemail.to`::
+`sendemail.toCmd`::
+`sendemail.smtpDomain`::
+`sendemail.smtpServer`::
+`sendemail.smtpServerPort`::
+`sendemail.smtpServerOption`::
+`sendemail.smtpUser`::
+`sendemail.imapSentFolder`::
+`sendemail.useImapOnly`::
+`sendemail.thread`::
+`sendemail.transferEncoding`::
+`sendemail.validate`::
+`sendemail.xmailer`::
These configuration variables all provide a default for
linkgit:git-send-email[1] command-line options. See its
documentation for details.
-sendemail.outlookidfix::
+`sendemail.outlookidfix`::
If `true`, makes linkgit:git-send-email[1] assume `--outlook-id-fix`,
and if `false` assume `--no-outlook-id-fix`. If not specified, it will
behave the same way as if `--outlook-id-fix` is not specified.
-sendemail.signedOffCc (deprecated)::
+`sendemail.signedOffCc` (deprecated)::
Deprecated alias for `sendemail.signedOffByCc`.
-sendemail.smtpBatchSize::
+`sendemail.smtpBatchSize`::
Number of messages to be sent per connection, after that a relogin
will happen. If the value is `0` or undefined, send all messages in
one connection.
See also the `--batch-size` option of linkgit:git-send-email[1].
-sendemail.smtpReloginDelay::
+`sendemail.smtpReloginDelay`::
Seconds to wait before reconnecting to the smtp server.
See also the `--relogin-delay` option of linkgit:git-send-email[1].
-sendemail.forbidSendmailVariables::
+`sendemail.forbidSendmailVariables`::
To avoid common misconfiguration mistakes, linkgit:git-send-email[1]
will abort with a warning if any configuration options for `sendmail`
exist. Set this variable to bypass the check.
diff --git a/Documentation/git-send-email.adoc b/Documentation/git-send-email.adoc
index dea3b86460..5c9ab39944 100644
--- a/Documentation/git-send-email.adoc
+++ b/Documentation/git-send-email.adoc
@@ -8,11 +8,11 @@ git-send-email - Send a collection of patches as emails
SYNOPSIS
--------
-[verse]
-'git send-email' [<options>] (<file>|<directory>)...
-'git send-email' [<options>] <format-patch-options>
-'git send-email' --dump-aliases
-'git send-email' --translate-aliases
+[synopsis]
+git send-email [<options>] (<file>|<directory>)...
+git send-email [<options>] <format-patch-options>
+git send-email --dump-aliases
+git send-email --translate-aliases
DESCRIPTION
@@ -48,24 +48,24 @@ OPTIONS
Composing
~~~~~~~~~
---annotate::
+`--annotate`::
Review and edit each patch you're about to send. Default is the value
of `sendemail.annotate`. See the CONFIGURATION section for
`sendemail.multiEdit`.
---bcc=<address>,...::
+`--bcc=<address>,...`::
Specify a `Bcc:` value for each email. Default is the value of
`sendemail.bcc`.
+
This option may be specified multiple times.
---cc=<address>,...::
+`--cc=<address>,...`::
Specify a starting `Cc:` value for each email.
Default is the value of `sendemail.cc`.
+
This option may be specified multiple times.
---compose::
+`--compose`::
Invoke a text editor (see GIT_EDITOR in linkgit:git-var[1])
to edit an introductory message for the patch series.
+
@@ -80,7 +80,7 @@ Missing `From` or `In-Reply-To` headers will be prompted for.
+
See the CONFIGURATION section for `sendemail.multiEdit`.
---from=<address>::
+`--from=<address>`::
Specify the sender of the emails. If not specified on the command line,
the value of the `sendemail.from` configuration option is used. If
neither the command-line option nor `sendemail.from` are set, then the
@@ -88,12 +88,12 @@ See the CONFIGURATION section for `sendemail.multiEdit`.
the value of `GIT_AUTHOR_IDENT`, or `GIT_COMMITTER_IDENT` if that is not
set, as returned by `git var -l`.
---reply-to=<address>::
+`--reply-to=<address>`::
Specify the address where replies from recipients should go to.
Use this if replies to messages should go to another address than what
is specified with the `--from` parameter.
---in-reply-to=<identifier>::
+`--in-reply-to=<identifier>`::
Make the first mail (or all the mails with `--no-thread`) appear as a
reply to the given Message-ID, which avoids breaking threads to
provide a new patch series.
@@ -115,8 +115,8 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
Only necessary if `--compose` is also set. If `--compose`
is not set, this will be prompted for.
---outlook-id-fix::
---no-outlook-id-fix::
+`--outlook-id-fix`::
+`--no-outlook-id-fix`::
Microsoft Outlook SMTP servers discard the Message-ID sent via email and
assign a new random Message-ID, thus breaking threads.
+
@@ -126,15 +126,15 @@ threading. Use it only when you know that the server reports the
rewritten Message-ID the same way as Outlook servers do.
+
Without this option specified, the fix is done by default when talking
-to 'smtp.office365.com' or 'smtp-mail.outlook.com'. Use
+to `smtp.office365.com` or `smtp-mail.outlook.com`. Use
`--no-outlook-id-fix` to disable even when talking to these two servers.
---subject=<string>::
+`--subject=<string>`::
Specify the initial subject of the email thread.
Only necessary if `--compose` is also set. If `--compose`
is not set, this will be prompted for.
---to=<address>,...::
+`--to=<address>,...`::
Specify the primary recipient of the emails generated. Generally, this
will be the upstream maintainer of the project involved. Default is the
value of the `sendemail.to` configuration value; if that is unspecified,
@@ -142,20 +142,20 @@ to 'smtp.office365.com' or 'smtp-mail.outlook.com'. Use
+
This option may be specified multiple times.
---8bit-encoding=<encoding>::
+`--8bit-encoding=<encoding>`::
When encountering a non-ASCII message or subject that does not
declare its encoding, add headers/quoting to indicate it is
- encoded in <encoding>. Default is the value of the
+ encoded in _<encoding>_. Default is the value of the
`sendemail.assume8bitEncoding`; if that is unspecified, this
will be prompted for if any non-ASCII files are encountered.
+
Note that no attempts whatsoever are made to validate the encoding.
---compose-encoding=<encoding>::
+`--compose-encoding=<encoding>`::
Specify encoding of compose message. Default is the value of the
`sendemail.composeEncoding`; if that is unspecified, UTF-8 is assumed.
---transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)::
+`--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)`::
Specify the transfer encoding to be used to send the message over SMTP.
`7bit` will fail upon encountering a non-ASCII message. `quoted-printable`
can be useful when the repository contains files that contain carriage
@@ -167,8 +167,8 @@ Note that no attempts whatsoever are made to validate the encoding.
Default is the value of the `sendemail.transferEncoding` configuration
value; if that is unspecified, default to `auto`.
---xmailer::
---no-xmailer::
+`--xmailer`::
+`--no-xmailer`::
Add (or prevent adding) the `X-Mailer:` header. By default,
the header is added, but it can be turned off by setting the
`sendemail.xmailer` configuration variable to `false`.
@@ -176,7 +176,7 @@ value; if that is unspecified, default to `auto`.
Sending
~~~~~~~
---envelope-sender=<address>::
+`--envelope-sender=<address>`::
Specify the envelope sender used to send the emails.
This is useful if your default address is not the address that is
subscribed to a list. In order to use the `From` address, set the
@@ -185,7 +185,7 @@ Sending
`sendemail.envelopeSender` configuration variable; if that is
unspecified, choosing the envelope sender is left to your MTA.
---sendmail-cmd=<command>::
+`--sendmail-cmd=<command>`::
Specify a command to run to send the email. The command should
be sendmail-like; specifically, it must support the `-i` option.
The command will be executed in the shell if necessary. Default
@@ -193,7 +193,7 @@ Sending
`--smtp-server` is also unspecified, `git send-email` will search
for `sendmail` in `/usr/sbin`, `/usr/lib` and `$PATH`.
---smtp-encryption=<encryption>::
+`--smtp-encryption=<encryption>`::
Specify in what way encrypting begins for the SMTP connection.
Valid values are `ssl` and `tls`. Any other value reverts to plain
(unencrypted) SMTP, which defaults to port 25.
@@ -207,14 +207,14 @@ Sending
documentation or your server configuration to make sure
for your own case. Default is the value of `sendemail.smtpEncryption`.
---smtp-domain=<FQDN>::
+`--smtp-domain=<FQDN>`::
Specify the Fully Qualified Domain Name (FQDN) used in the
HELO/EHLO command to the SMTP server. Some servers require the
FQDN to match your IP address. If not set, `git send-email` attempts
to determine your FQDN automatically. Default is the value of
`sendemail.smtpDomain`.
---smtp-auth=<mechanisms>::
+`--smtp-auth=<mechanisms>`::
Whitespace-separated list of allowed SMTP-AUTH mechanisms. This setting
forces using only the listed mechanisms. Example:
+
@@ -229,7 +229,7 @@ is specified, all mechanisms supported by the SASL library can be used. The
special value `none` maybe specified to completely disable authentication
independently of `--smtp-user`.
---smtp-pass[=<password>]::
+`--smtp-pass[=<password>]`::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
the password. Default is the value of `sendemail.smtpPass`,
@@ -241,10 +241,10 @@ or on the command line. If a username has been specified (with
specified (with `--smtp-pass` or `sendemail.smtpPass`), then
a password is obtained using linkgit:git-credential[1].
---no-smtp-auth::
+`--no-smtp-auth`::
Disable SMTP authentication. Short hand for `--smtp-auth=none`.
---smtp-server=<host>::
+`--smtp-server=<host>`::
Specify the outgoing SMTP server to use (e.g.
`smtp.example.com` or a raw IP address). If unspecified, and if
`--sendmail-cmd` is also unspecified, the default is to search
@@ -257,7 +257,7 @@ option. This method does not support passing arguments or using plain
command names. For those use cases, consider using `--sendmail-cmd`
instead.
---smtp-server-port=<port>::
+`--smtp-server-port=<port>`::
Specify a port different from the default port (SMTP
servers typically listen to smtp port 25, but may also listen to
submission port 587, or the common SSL smtp port 465);
@@ -265,7 +265,7 @@ instead.
are also accepted. The port can also be set with the
`sendemail.smtpServerPort` configuration variable.
---smtp-server-option=<option>::
+`--smtp-server-option=<option>`::
Specify the outgoing SMTP server option to use.
Default value can be specified by the `sendemail.smtpServerOption`
configuration option.
@@ -274,15 +274,15 @@ The `--smtp-server-option` option must be repeated for each option you want
to pass to the server. Likewise, different lines in the configuration files
must be used for each option.
---smtp-ssl::
+`--smtp-ssl`::
Legacy alias for `--smtp-encryption ssl`.
---smtp-ssl-cert-path <path>::
+`--smtp-ssl-cert-path <path>`::
Path to a store of trusted CA certificates for SMTP SSL/TLS
certificate validation (either a directory that has been processed
by `c_rehash`, or a single file containing one or more PEM format
certificates concatenated together: see the description of the
- `-CAfile` _<file>_ and the `-CApath` _<dir>_ options of
+ `-CAfile <file>` and the `-CApath <dir>` options of
https://docs.openssl.org/master/man1/openssl-verify/
[OpenSSL's verify(1) manual page] for more information on these).
Set it to an empty string to disable certificate verification.
@@ -290,7 +290,7 @@ must be used for each option.
variable, if set, or the backing SSL library's compiled-in default
otherwise (which should be the best choice on most platforms).
---smtp-ssl-client-cert <path>::
+`--smtp-ssl-client-cert <path>`::
Path to the client certificate file to present if requested by the
server. This option is required when the server is set up to verify
client certificates. If the corresponding private key is not included in
@@ -299,7 +299,7 @@ must be used for each option.
to the value of the `sendemail.smtpSSLClientCert` configuration
variable, if set.
---smtp-ssl-client-key <path>::
+`--smtp-ssl-client-key <path>`::
Path to the client private key file that corresponds to the client
certificate. To avoid misconfiguration, this option must be used in
conjunction with the `sendemail.smtpSSLClientKey` configuration variable
@@ -309,17 +309,17 @@ must be used for each option.
more details. Defaults to the value of the `sendemail.smtpSSLClientKey`
configuration variable, if set.
---smtp-user=<user>::
+`--smtp-user=<user>`::
Username for SMTP-AUTH. Default is the value of `sendemail.smtpUser`;
if a username is not specified (with `--smtp-user` or `sendemail.smtpUser`),
then authentication is not attempted.
---smtp-debug=(0|1)::
+`--smtp-debug=(0|1)`::
Enable (1) or disable (0) debug output. If enabled, SMTP
commands and replies will be printed. Useful to debug TLS
connection and authentication problems.
---imap-sent-folder=<folder>::
+`--imap-sent-folder=<folder>`::
Some email providers (e.g. iCloud) do not send a copy of the emails sent
using SMTP to the `Sent` folder or similar in your mailbox. Use this option
to use `git imap-send` to send a copy of the emails to the folder specified
@@ -331,8 +331,8 @@ must be used for each option.
This feature requires setting up `git imap-send`. See linkgit:git-imap-send[1]
for instructions.
---use-imap-only::
---no-use-imap-only::
+`--use-imap-only`::
+`--no-use-imap-only`::
If this is set, all emails will only be copied to the IMAP folder specified
with `--imap-sent-folder` or `sendemail.imapSentFolder` and will not be sent
to the recipients. Useful if you just want to create a draft of the emails
@@ -344,8 +344,8 @@ for instructions.
This feature requires setting up `git imap-send`. See linkgit:git-imap-send[1]
for instructions.
---batch-size=<num>::
- Some email servers (e.g. 'smtp.163.com') limit the number of emails to be
+`--batch-size=<num>`::
+ Some email servers (e.g. `smtp.163.com`) limit the number of emails to be
sent per session (connection) and this will lead to a failure when
sending many messages. With this option, send-email will disconnect after
sending _<num>_ messages and wait for a few seconds
@@ -354,7 +354,7 @@ for instructions.
retype your password every time this happens. Defaults to the
`sendemail.smtpBatchSize` configuration variable.
---relogin-delay=<int>::
+`--relogin-delay=<int>`::
Waiting _<int>_ seconds before reconnecting to SMTP server. Used together
with `--batch-size` option. Defaults to the `sendemail.smtpReloginDelay`
configuration variable.
@@ -362,29 +362,29 @@ for instructions.
Automating
~~~~~~~~~~
---no-to::
---no-cc::
---no-bcc::
+`--no-to`::
+`--no-cc`::
+`--no-bcc`::
Clear any list of `To:`, `Cc:`, `Bcc:` addresses previously
set via config.
---no-identity::
+`--no-identity`::
Clear the previously read value of `sendemail.identity` set
via config, if any.
---to-cmd=<command>::
+`--to-cmd=<command>`::
Specify a command to execute once per patch file which
should generate patch file specific `To:` entries.
Output of this command must be single email address per line.
Default is the value of `sendemail.toCmd` configuration value.
---cc-cmd=<command>::
+`--cc-cmd=<command>`::
Specify a command to execute once per patch file which
should generate patch file specific `Cc:` entries.
Output of this command must be single email address per line.
Default is the value of `sendemail.ccCmd` configuration value.
---header-cmd=<command>::
+`--header-cmd=<command>`::
Specify a command that is executed once per outgoing message
and output RFC 2822 style header lines to be inserted into
them. When the `sendemail.headerCmd` configuration variable is
@@ -392,11 +392,11 @@ Automating
at the command line, its value takes precedence over the
`sendemail.headerCmd` configuration variable.
---no-header-cmd::
+`--no-header-cmd`::
Disable any header command in use.
---chain-reply-to::
---no-chain-reply-to::
+`--chain-reply-to`::
+`--no-chain-reply-to`::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with `--no-chain-reply-to`, all emails after
the first will be sent as replies to the first email sent. When using
@@ -404,34 +404,34 @@ Automating
entire patch series. Disabled by default, but the `sendemail.chainReplyTo`
configuration variable can be used to enable it.
---identity=<identity>::
+`--identity=<identity>`::
A configuration identity. When given, causes values in the
`sendemail.<identity>` subsection to take precedence over
values in the `sendemail` section. The default identity is
the value of `sendemail.identity`.
---signed-off-by-cc::
---no-signed-off-by-cc::
+`--signed-off-by-cc`::
+`--no-signed-off-by-cc`::
If this is set, add emails found in the `Signed-off-by` trailer or `Cc:`
lines to the cc list. Default is the value of `sendemail.signedOffByCc`
configuration value; if that is unspecified, default to
`--signed-off-by-cc`.
---cc-cover::
---no-cc-cover::
+`--cc-cover`::
+`--no-cc-cover`::
If this is set, emails found in `Cc:` headers in the first patch of
the series (typically the cover letter) are added to the cc list
for each email set. Default is the value of `sendemail.ccCover`
configuration value; if that is unspecified, default to `--no-cc-cover`.
---to-cover::
---no-to-cover::
+`--to-cover`::
+`--no-to-cover`::
If this is set, emails found in `To:` headers in the first patch of
the series (typically the cover letter) are added to the to list
for each email set. Default is the value of `sendemail.toCover`
configuration value; if that is unspecified, default to `--no-to-cover`.
---suppress-cc=<category>::
+`--suppress-cc=<category>`::
Specify an additional category of recipients to suppress the
auto-cc of:
+
@@ -456,14 +456,14 @@ Default is the value of `sendemail.suppressCc` configuration value; if
that is unspecified, default to `self` if `--suppress-from` is
specified, as well as `body` if `--no-signed-off-by-cc` is specified.
---suppress-from::
---no-suppress-from::
+`--suppress-from`::
+`--no-suppress-from`::
If this is set, do not add the `From:` address to the `Cc:` list.
Default is the value of `sendemail.suppressFrom` configuration
value; if that is unspecified, default to `--no-suppress-from`.
---thread::
---no-thread::
+`--thread`::
+`--no-thread`::
If this is set, the `In-Reply-To` and `References` headers will be
added to each email sent. Whether each mail refers to the
previous email (`deep` threading per `git format-patch`
@@ -481,8 +481,8 @@ exists when `git send-email` is asked to add it (especially note that
Failure to do so may not produce the expected result in the
recipient's MUA.
---mailmap::
---no-mailmap::
+`--mailmap`::
+`--no-mailmap`::
Use the mailmap file (see linkgit:gitmailmap[5]) to map all
addresses to their canonical real name and email address. Additional
mailmap data specific to `git send-email` may be provided using the
@@ -492,7 +492,7 @@ recipient's MUA.
Administering
~~~~~~~~~~~~~
---confirm=<mode>::
+`--confirm=<mode>`::
Confirm just before sending:
+
--
@@ -508,22 +508,22 @@ Default is the value of `sendemail.confirm` configuration value; if that
is unspecified, default to `auto` unless any of the suppress options
have been specified, in which case default to `compose`.
---dry-run::
+`--dry-run`::
Do everything except actually send the emails.
---format-patch::
---no-format-patch::
+`--format-patch`::
+`--no-format-patch`::
When an argument may be understood either as a reference or as a file name,
choose to understand it as a format-patch argument (`--format-patch`)
or as a file name (`--no-format-patch`). By default, when such a conflict
occurs, `git send-email` will fail.
---quiet::
+`--quiet`::
Make `git send-email` less verbose. One line per email should be
all that is output.
---validate::
---no-validate::
+`--validate`::
+`--no-validate`::
Perform sanity checks on patches.
Currently, validation means the following:
+
@@ -539,20 +539,20 @@ have been specified, in which case default to `compose`.
Default is the value of `sendemail.validate`; if this is not set,
default to `--validate`.
---force::
+`--force`::
Send emails even if safety checks would prevent it.
Information
~~~~~~~~~~~
---dump-aliases::
+`--dump-aliases`::
Instead of the normal operation, dump the shorthand alias names from
the configured alias file(s), one per line in alphabetical order. Note
that this only includes the alias name and not its expanded email addresses.
See `sendemail.aliasesFile` for more information about aliases.
---translate-aliases::
+`--translate-aliases`::
Instead of the normal operation, read from standard input and
interpret each line as an email alias. Translate it according to the
configured alias file(s). Output each translated name and email
@@ -718,7 +718,7 @@ include::format-patch-caveats.adoc[]
SEE ALSO
--------
-linkgit:git-format-patch[1], linkgit:git-imap-send[1], mbox(5)
+linkgit:git-format-patch[1], linkgit:git-imap-send[1], `mbox`(5)
GIT
---
--
gitgitgadget
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 4/4] doc: convert git-request-pull synopsis and options to new style
2026-07-19 19:54 [PATCH 0/4] A new batch of synopsis conversion Jean-Noël Avila via GitGitGadget
` (2 preceding siblings ...)
2026-07-19 19:54 ` [PATCH 3/4] doc: convert git-send-email " Jean-Noël Avila via GitGitGadget
@ 2026-07-19 19:54 ` Jean-Noël Avila via GitGitGadget
2026-07-19 23:47 ` Junio C Hamano
3 siblings, 1 reply; 10+ messages in thread
From: Jean-Noël Avila via GitGitGadget @ 2026-07-19 19:54 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila, Jean-Noël Avila
From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
* Replace [verse] with [synopsis] in the SYNOPSIS block
* remove single-quote formatting from the command name
* backtick-quote the flag
* use _<placeholder>_ form for positional parameter terms
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
Documentation/git-request-pull.adoc | 38 +++++++++++++++++------------
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-request-pull.adoc b/Documentation/git-request-pull.adoc
index 15dcbb6d91..8b6642b312 100644
--- a/Documentation/git-request-pull.adoc
+++ b/Documentation/git-request-pull.adoc
@@ -7,8 +7,8 @@ git-request-pull - Generates a summary of pending changes
SYNOPSIS
--------
-[verse]
-'git request-pull' [-p] <start> <URL> [<end>]
+[synopsis]
+git request-pull [-p] <start> <URL> [<end>]
DESCRIPTION
-----------
@@ -19,28 +19,28 @@ begins with the branch description, summarizes
the changes, and indicates from where they can be pulled.
The upstream project is expected to have the commit named by
-`<start>` and the output asks it to integrate the changes you made
-since that commit, up to the commit named by `<end>`, by visiting
-the repository named by `<URL>`.
+_<start>_ and the output asks it to integrate the changes you made
+since that commit, up to the commit named by _<end>_, by visiting
+the repository named by _<URL>_.
OPTIONS
-------
--p::
+`-p`::
Include patch text in the output.
-<start>::
+_<start>_::
Commit to start at. This names a commit that is already in
the upstream history.
-<URL>::
+_<URL>_::
The repository URL to be pulled from.
-<end>::
- Commit to end at (defaults to HEAD). This names the commit
+_<end>_::
+ Commit to end at (defaults to `HEAD`). This names the commit
at the tip of the history you are asking to be pulled.
+
-When the repository named by `<URL>` has the commit at a tip of a
+When the repository named by _<URL>_ has the commit at a tip of a
ref that is different from the ref you have locally, you can use the
`<local>:<remote>` syntax, to have its local name, a colon `:`, and
its remote name.
@@ -54,11 +54,15 @@ the `v1.0` release, and want it to be integrated into the project.
First you push that change to your public repository for others to
see:
- git push https://git.ko.xz/project master
+-----
+git push https://git.ko.xz/project master
+-----
Then, you run this command:
- git request-pull v1.0 https://git.ko.xz/project master
+------
+git request-pull v1.0 https://git.ko.xz/project master
+------
which will produce a request to the upstream, summarizing the
changes between the `v1.0` release and your `master`, to pull it
@@ -67,11 +71,15 @@ from your public repository.
If you pushed your change to a branch whose name is different from
the one you have locally, e.g.
- git push https://git.ko.xz/project master:for-linus
+-----
+git push https://git.ko.xz/project master:for-linus
+-----
then you can ask that to be pulled with
- git request-pull v1.0 https://git.ko.xz/project master:for-linus
+-----
+git request-pull v1.0 https://git.ko.xz/project master:for-linus
+-----
GIT
--
gitgitgadget
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH 4/4] doc: convert git-request-pull synopsis and options to new style
2026-07-19 19:54 ` [PATCH 4/4] doc: convert git-request-pull " Jean-Noël Avila via GitGitGadget
@ 2026-07-19 23:47 ` Junio C Hamano
2026-07-20 20:39 ` Jean-Noël AVILA
0 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2026-07-19 23:47 UTC (permalink / raw)
To: Jean-Noël Avila via GitGitGadget; +Cc: git, Jean-Noël Avila
"Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com> writes:
> @@ -54,11 +54,15 @@ the `v1.0` release, and want it to be integrated into the project.
> First you push that change to your public repository for others to
> see:
>
> - git push https://git.ko.xz/project master
> +-----
> +git push https://git.ko.xz/project master
> +-----
>
> Then, you run this command:
>
> - git request-pull v1.0 https://git.ko.xz/project master
> +------
> +git request-pull v1.0 https://git.ko.xz/project master
> +------
>
> which will produce a request to the upstream, summarizing the
> changes between the `v1.0` release and your `master`, to pull it
> @@ -67,11 +71,15 @@ from your public repository.
> If you pushed your change to a branch whose name is different from
> the one you have locally, e.g.
>
> - git push https://git.ko.xz/project master:for-linus
> +-----
> +git push https://git.ko.xz/project master:for-linus
> +-----
>
> then you can ask that to be pulled with
>
> - git request-pull v1.0 https://git.ko.xz/project master:for-linus
> +-----
> +git request-pull v1.0 https://git.ko.xz/project master:for-linus
> +-----
Is there a widely accepted guideline among AsciiDoc users governing
how many dashes should delimit these blocks, other than "at least
four, with the opening and closing counts matching"? If so, what is
it? We see five, six, five, and five dashes in the proposed changes
above, and in '[PATCH 1/4]' we saw nine. Even if varying counts are
functionally equivalent, the inconsistency is a bit distracting.
Thanks.
[Footnote]
* an excerpt from [PATCH 1/4]
diff --git a/Documentation/git-imap-send.adoc b/Documentation/git-imap-send.adoc
index 538b91afc0..dd1e0a3718 100644
--- a/Documentation/git-imap-send.adoc
+++ b/Documentation/git-imap-send.adoc
@@ -192,7 +192,10 @@ supports only `XOAUTH2` as the mechanism.
Once the commits are ready to be sent, run the following command:
- $ git format-patch --cover-letter -M --stdout origin/master | git imap-send
+
+---------
+$ git format-patch --cover-letter -M --stdout origin/master | git imap-send
+---------
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 4/4] doc: convert git-request-pull synopsis and options to new style
2026-07-19 23:47 ` Junio C Hamano
@ 2026-07-20 20:39 ` Jean-Noël AVILA
2026-07-20 21:26 ` Junio C Hamano
0 siblings, 1 reply; 10+ messages in thread
From: Jean-Noël AVILA @ 2026-07-20 20:39 UTC (permalink / raw)
To: Jean-Noël Avila via GitGitGadget, Junio C Hamano; +Cc: git
On Monday, 20 July 2026 01:47:02 CEST Junio C Hamano wrote:
> "Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > @@ -54,11 +54,15 @@ the `v1.0` release, and want it to be integrated into
the
> > project.>
> > First you push that change to your public repository for others to
> >
> > see:
> > - git push https://git.ko.xz/project master
> > +-----
> > +git push https://git.ko.xz/project master
> > +-----
> >
> > Then, you run this command:
> > - git request-pull v1.0 https://git.ko.xz/project master
> > +------
> > +git request-pull v1.0 https://git.ko.xz/project master
> > +------
> >
> > which will produce a request to the upstream, summarizing the
> > changes between the `v1.0` release and your `master`, to pull it
> >
> > @@ -67,11 +71,15 @@ from your public repository.
> >
> > If you pushed your change to a branch whose name is different from
> > the one you have locally, e.g.
> >
> > - git push https://git.ko.xz/project master:for-linus
> > +-----
> > +git push https://git.ko.xz/project master:for-linus
> > +-----
> >
> > then you can ask that to be pulled with
> >
> > - git request-pull v1.0 https://git.ko.xz/project master:for-linus
> > +-----
> > +git request-pull v1.0 https://git.ko.xz/project master:for-linus
> > +-----
>
> Is there a widely accepted guideline among AsciiDoc users governing
> how many dashes should delimit these blocks, other than "at least
> four, with the opening and closing counts matching"? If so, what is
> it? We see five, six, five, and five dashes in the proposed changes
> above, and in '[PATCH 1/4]' we saw nine. Even if varying counts are
> functionally equivalent, the inconsistency is a bit distracting.
>
> Thanks.
>
> [Footnote]
>
> * an excerpt from [PATCH 1/4]
>
> diff --git a/Documentation/git-imap-send.adoc b/Documentation/git-imap-
send.adoc
> index 538b91afc0..dd1e0a3718 100644
> --- a/Documentation/git-imap-send.adoc
> +++ b/Documentation/git-imap-send.adoc
> @@ -192,7 +192,10 @@ supports only `XOAUTH2` as the mechanism.
>
> Once the commits are ready to be sent, run the following command:
>
> - $ git format-patch --cover-letter -M --stdout origin/master | git imap-
send
> +
> +---------
> +$ git format-patch --cover-letter -M --stdout origin/master | git imap-send
> +---------
"Widely accepted", I do not know. I would better frame it as "because at least
four is needed and I'm lazy, then it's four". I'm not expert enough the
asciidoc specification to have a definitive answer of mine, but the
asciidoctor specification says exactly four [1]
We could indeed apply the rule of 4 dashes by default.
Note that this only applies because it is a listing block which does not
accept nesting.
I will reroll.
[1]: https://docs.asciidoctor.org/asciidoc/latest/verbatim/listing-blocks/
#delimited-listing-block
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 4/4] doc: convert git-request-pull synopsis and options to new style
2026-07-20 20:39 ` Jean-Noël AVILA
@ 2026-07-20 21:26 ` Junio C Hamano
0 siblings, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2026-07-20 21:26 UTC (permalink / raw)
To: Jean-Noël AVILA; +Cc: Jean-Noël Avila via GitGitGadget, git
Jean-Noël AVILA <jn.avila@free.fr> writes:
> "Widely accepted", I do not know. I would better frame it as "because at least
> four is needed and I'm lazy, then it's four". I'm not expert enough the
> asciidoc specification to have a definitive answer of mine, but the
> asciidoctor specification says exactly four [1]
>
> We could indeed apply the rule of 4 dashes by default.
>
> Note that this only applies because it is a listing block which does not
> accept nesting.
>
> I will reroll.
Thanks. Sounds like a good plan to me.
^ permalink raw reply [flat|nested] 10+ messages in thread