public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>
To: "Jean-Noël Avila" <gitgitgadget@gmail.com>, git@vger.kernel.org
Cc: "Jean-Noël AVILA" <jn.avila@free.fr>
Subject: Re: [PATCH 1/4] convert git-submodule doc to synopsis style
Date: Sun, 01 Feb 2026 13:04:02 +0100	[thread overview]
Message-ID: <83cef072-530a-423b-ba89-26eb6bc63e67@app.fastmail.com> (raw)
In-Reply-To: <05e68e28257cd450463d253abe9b2995759bdc10.1769202903.git.gitgitgadget@gmail.com>

On Fri, Jan 23, 2026, at 22:15, Jean-Noël Avila via GitGitGadget wrote:
> From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
>
>  * convert commands to synopsis style
>  * use _<placeholder>_ for arguments
>  * convert inline lists into proper definition lists
>  * minor formatting fixes
>
> Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
> ---
>  Documentation/git-submodule.adoc | 369 ++++++++++++++++---------------
>  1 file changed, 185 insertions(+), 184 deletions(-)
>
> diff --git a/Documentation/git-submodule.adoc b/Documentation/git-submodule.adoc
> index 95beaee561..188212508e 100644
> --- a/Documentation/git-submodule.adoc
> +++ b/Documentation/git-submodule.adoc
> @@ -8,19 +8,19 @@ git-submodule - Initialize, update or inspect submodules
>
>  SYNOPSIS
>  --------
> -[verse]
> -'git submodule' [--quiet] [--cached]
> -'git submodule' [--quiet] add [<options>] [--] <repository> [<path>]
> -'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> -'git submodule' [--quiet] init [--] [<path>...]
> -'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...)
> -'git submodule' [--quiet] update [<options>] [--] [<path>...]
> -'git submodule' [--quiet] set-branch [<options>] [--] <path>
> -'git submodule' [--quiet] set-url [--] <path> <newurl>
> -'git submodule' [--quiet] summary [<options>] [--] [<path>...]
> -'git submodule' [--quiet] foreach [--recursive] <command>
> -'git submodule' [--quiet] sync [--recursive] [--] [<path>...]
> -'git submodule' [--quiet] absorbgitdirs [--] [<path>...]
> +[synopsis]
> +git submodule [--quiet] [--cached]
> +git submodule [--quiet] add [<options>] [--] <repository> [<path>]
> +git submodule [--quiet] status [--cached] [--recursive] [--] [<path>...]
> +git submodule [--quiet] init [--] [<path>...]
> +git submodule [--quiet] deinit [-f|--force] (--all|[--] <path>...)
> +git submodule [--quiet] update [<options>] [--] [<path>...]
> +git submodule [--quiet] set-branch [<options>] [--] <path>
> +git submodule [--quiet] set-url [--] <path> <newurl>
> +git submodule [--quiet] summary [<options>] [--] [<path>...]
> +git submodule [--quiet] foreach [--recursive] <command>
> +git submodule [--quiet] sync [--recursive] [--] [<path>...]
> +git submodule [--quiet] absorbgitdirs [--] [<path>...]

Good.

>
>
>  DESCRIPTION
> @@ -34,16 +34,16 @@ COMMANDS
>  With no arguments, shows the status of existing submodules.  Several
>  subcommands are available to perform operations on the submodules.
>
> -add [-b <branch>] [-f|--force] [--name <name>] [--reference
> <repository>] [--ref-format <format>] [--depth <depth>] [--]
> <repository> [<path>]::
> +`add [-b <branch>] [-f | --force] [--name <name>] [--reference
> <repository>] [--ref-format <format>] [--depth <depth>] [--]
> <repository> [<path>]`::
>  	Add the given repository as a submodule at the given path
>  	to the changeset to be committed next to the current
>  	project: the current project is termed the "superproject".
>  +
> -<repository> is the URL of the new submodule's origin repository.
> -This may be either an absolute URL, or (if it begins with ./
> -or ../), the location relative to the superproject's default remote
> -repository (Please note that to specify a repository 'foo.git'
> -which is located right next to a superproject 'bar.git', you'll
> +_<repository>_ is the URL of the new submodule's origin repository.
> +This may be either an absolute URL, or (if it begins with `./`
> +or `../`), the location relative to the superproject's default remote
> +repository (Please note that to specify a repository `foo.git`
> +which is located right next to a superproject `bar.git`, you'll
>  have to use `../foo.git` instead of `./foo.git` - as one might expect
>  when following the rules for relative URLs - because the evaluation
>  of relative URLs in Git is identical to that of relative directories).

Good. There is also an "origin" outside the context lines here that you
may want to replace with `origin`:

    , "origin" is assumed to be the default remote.

> @@ -55,13 +55,13 @@ If the superproject doesn't have a default remote
> configured
>  the superproject is its own authoritative upstream and the current
>  working directory is used instead.
>  +
> -The optional argument <path> is the relative location for the cloned
> -submodule to exist in the superproject. If <path> is not given, the
> -canonical part of the source repository is used ("repo" for
> -"/path/to/repo.git" and "foo" for "host.xz:foo/.git"). If <path>
> +The optional argument _<path>_ is the relative location for the cloned
> +submodule to exist in the superproject. If _<path>_ is not given, the
> +canonical part of the source repository is used (`repo` for
> +`/path/to/repo.git` and `foo` for `host.xz:foo/.git`). If _<path>_
>  exists and is already a valid Git repository, then it is staged
> -for commit without cloning. The <path> is also used as the submodule's
> -logical name in its configuration entries unless `--name` is used
> +for commit without cloning. The _<path>_ is also used as the
> submodule's
> +logical name in its configuration entries unless `--name <name>` is
> used
>  to specify a logical name.
>  +
>  The given URL is recorded into `.gitmodules` for use by subsequent
> users

Looks correct.

> @@ -75,10 +75,10 @@ URL in `.gitmodules`.
>  If `--ref-format <format>`  is specified, the ref storage format of
> newly
>  cloned submodules will be set accordingly.
>
> -status [--cached] [--recursive] [--] [<path>...]::
> +`status [--cached] [--recursive] [--] [<path>...]`::
>  	Show the status of the submodules. This will print the SHA-1 of the
>  	currently checked out commit for each submodule, along with the
> -	submodule path and the output of 'git describe' for the
> +	submodule path and the output of `git describe` for the

Maybe `linkgit` for git-describe(1).

>  	SHA-1. Each SHA-1 will possibly be prefixed with `-` if the submodule
> is
>  	not initialized, `+` if the currently checked out submodule commit
>  	does not match the SHA-1 found in the index of the containing

Good.

> @@ -95,7 +95,7 @@ submodules with respect to the commit recorded in the
> index or the HEAD,
>  linkgit:git-status[1] and linkgit:git-diff[1] will provide that
> information
>  too (and can also report changes to a submodule's work tree).
>
> -init [--] [<path>...]::
> +`init [--] [<path>...]`::
>  	Initialize the submodules recorded in the index (which were
>  	added and committed elsewhere) by setting `submodule.$name.url`
>  	in `.git/config`, using the same setting from `.gitmodules` as

Good.

> @@ -103,7 +103,7 @@ init [--] [<path>...]::
>  	the default remote. If there is no default remote, the current
>  	repository will be assumed to be upstream.
>  +
> -Optional <path> arguments limit which submodules will be initialized.
> +Optional _<path>_ arguments limit which submodules will be initialized.
>  If no path is specified and submodule.active has been configured,
> submodules
>  configured to be active will be initialized, otherwise all submodules
> are
>  initialized.
> @@ -116,12 +116,12 @@ that is set to a custom command is *not* copied
> for security reasons.
>  You can then customize the submodule clone URLs in `.git/config`
>  for your local setup and proceed to `git submodule update`;
>  you can also just use `git submodule update --init` without
> -the explicit 'init' step if you do not intend to customize
> +the explicit `init` step if you do not intend to customize
>  any submodule locations.
>  +
>  See the add subcommand for the definition of default remote.
>
> -deinit [-f|--force] (--all|[--] <path>...)::
> +`deinit [-f | --force] (--all|[--] <path>...)`::
>  	Unregister the given submodules, i.e. remove the whole
>  	`submodule.$name` section from .git/config together with their work
>  	tree. Further calls to `git submodule update`, `git submodule foreach`
> @@ -139,7 +139,7 @@ If you really want to remove a submodule from the
> repository and commit
>  that use linkgit:git-rm[1] instead. See linkgit:gitsubmodules[7] for
> removal
>  options.

Good.

>
> -update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow]
> [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>]
> [--ref-format <format>] [--depth <depth>] [--recursive] [--jobs <n>]
> [--[no-]single-branch] [--filter <filter-spec>] [--] [<path>...]::
> +`update [--init] [--remote] [-N | --no-fetch]
> [--[no-]recommend-shallow] [-f | --force] [--checkout | --rebase |
> --merge] [--reference <repository>] [--ref-format <format>] [--depth
> <depth>] [--recursive] [--jobs <n>] [--[no-]single-branch] [--filter
> <filter-spec>] [--] [<path>...]`::
>  +
>  --
>  Update the registered submodules to match what the superproject
> @@ -148,38 +148,38 @@ in submodules and updating the working tree of
>  the submodules. The "updating" can be done in several ways depending
>  on command line options and the value of `submodule.<name>.update`
>  configuration variable. The command line option takes precedence over
> -the configuration variable. If neither is given, a 'checkout' is
> performed.
> +the configuration variable. If neither is given, a `checkout` is
> performed.
>  (note: what is in `.gitmodules` file is irrelevant at this point;
>  see `git submodule init` above for how `.gitmodules` is used).
> -The 'update' procedures supported both from the command line as well as
> +The `update` procedures supported both from the command line as well as
>  through the `submodule.<name>.update` configuration are:
>
> -	checkout;; the commit recorded in the superproject will be
> -	    checked out in the submodule on a detached HEAD.
> +`checkout`;; the commit recorded in the superproject will be
> +checked out in the submodule on a detached HEAD.
>  +
>  If `--force` is specified, the submodule will be checked out (using
>  `git checkout --force`), even if the commit specified
>  in the index of the containing repository already matches the commit
>  checked out in the submodule.
>
> -	rebase;; the current branch of the submodule will be rebased
> -	    onto the commit recorded in the superproject.
> +`rebase`;; the current branch of the submodule will be rebased
> +onto the commit recorded in the superproject.
>
> -	merge;; the commit recorded in the superproject will be merged
> -	    into the current branch in the submodule.
> +`merge`;; the commit recorded in the superproject will be merged
> +into the current branch in the submodule.
>
>  The following update procedures have additional limitations:
>
> -	custom command;; mechanism for running arbitrary commands with the
> -	    commit ID as an argument. Specifically, if the
> -	    `submodule.<name>.update` configuration variable is set to
> -	    `!custom command`, the object name of the commit recorded in the
> -	    superproject for the submodule is appended to the `custom command`
> -	    string and executed. Note that this mechanism is not supported in
> -	    the `.gitmodules` file or on the command line.
> +`!<custom-command>`;; mechanism for running arbitrary commands with the
> +commit ID as an argument. Specifically, if the
> +`submodule.<name>.update` configuration variable is set to
> +`!<custom-command>`, the object name of the commit recorded in the
> +superproject for the submodule is appended to the _<custom-command>_
> +string and executed. Note that this mechanism is not supported in
> +the `.gitmodules` file or on the command line.
>
> -	none;; the submodule is not updated. This update procedure is not
> -	    allowed on the command line.
> +`none`;; the submodule is not updated. This update procedure is not
> +allowed on the command line.
>
>  If the submodule is not yet initialized, and you just want to use the
>  setting as stored in `.gitmodules`, you can automatically initialize
> the
> @@ -195,20 +195,20 @@ If `--filter <filter-spec>` is specified, the
> given partial clone filter will be
>  applied to the submodule. See linkgit:git-rev-list[1] for details on
> filter
>  specifications.
>  --
> -set-branch (-b|--branch) <branch> [--] <path>::
> -set-branch (-d|--default) [--] <path>::
> -	Sets the default remote tracking branch for the submodule. The
> +`set-branch (-b|--branch) <branch> [--] <path>`::
> +`set-branch (-d|--default) [--] <path>`::
> +	Set the default remote tracking branch for the submodule. The
>  	`--branch` option allows the remote branch to be specified. The
> -	`--default` option removes the submodule.<name>.branch configuration
> -	key, which causes the tracking branch to default to the remote 'HEAD'.
> +	`--default` option removes the `submodule.<name>.branch` configuration
> +	key, which causes the tracking branch to default to the remote `HEAD`.
>
> -set-url [--] <path> <newurl>::
> -	Sets the URL of the specified submodule to <newurl>. Then, it will
> +`set-url [--] <path> <newurl>`::
> +	Set the URL of the specified submodule to _<newurl>_. Then, it will
>  	automatically synchronize the submodule's new remote URL
>  	configuration.
>
> -summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--]
> [<path>...]::
> -	Show commit summary between the given commit (defaults to HEAD) and
> +`summary [--cached | --files] [(-n|--summary-limit) <n>] [commit] [--]
> [<path>...]`::
> +	Show commit summary between the given commit (defaults to `HEAD`) and
>  	working tree/index. For a submodule in question, a series of commits
>  	in the submodule between the given super project commit and the
>  	index or working tree (switched by `--cached`) are shown. If the
> option
> @@ -220,27 +220,31 @@ summary [--cached|--files] [(-n|--summary-limit)
> <n>] [commit] [--] [<path>...]:
>  Using the `--submodule=log` option with linkgit:git-diff[1] will
> provide that
>  information too.
>
> -foreach [--recursive] <command>::
> -	Evaluates an arbitrary shell command in each checked out submodule.
> -	The command has access to the variables $name, $sm_path, $displaypath,
> -	$sha1 and $toplevel:
> -	$name is the name of the relevant submodule section in `.gitmodules`,
> -	$sm_path is the path of the submodule as recorded in the immediate
> -	superproject, $displaypath contains the relative path from the
> -	current working directory to the submodules root directory,
> -	$sha1 is the commit as recorded in the immediate
> -	superproject, and $toplevel is the absolute path to the top-level
> -	of the immediate superproject.
> -	Note that to avoid conflicts with '$PATH' on Windows, the '$path'
> -	variable is now a deprecated synonym of '$sm_path' variable.
> -	Any submodules defined in the superproject but not checked out are
> -	ignored by this command. Unless given `--quiet`, foreach prints the name
> -	of each submodule before evaluating the command.
> -	If `--recursive` is given, submodules are traversed recursively (i.e.
> -	the given shell command is evaluated in nested submodules as well).
> -	A non-zero return from the command in any submodule causes
> -	the processing to terminate. This can be overridden by adding '|| :'
> -	to the end of the command.
> +`foreach [--recursive] <command>`::
> +	Evaluate an arbitrary shell _<command>_ in each checked out submodule.
> +	The command has access to the variables `$name`, `$sm_path`, `$displaypath`,
> +	`$sha1` and `$toplevel`:
> ++
> +--
> +`$name`;; the name of the relevant submodule section in `.gitmodules`
> +`$sm_path`;; the path of the submodule as recorded in the immediate
> +	superproject
> +`$displaypath`;; the relative path from the
> +	current working directory to the submodules root directory
> +`$sha1`;; the commit as recorded in the immediate superproject
> +`$toplevel`;; the absolute path to the top-level of the immediate superproject.
> +--
> ++
> +Note that to avoid conflicts with `$PATH` on Windows, the `$path`
> +variable is now a deprecated synonym of `$sm_path` variable.
> +Any submodules defined in the superproject but not checked out are
> +ignored by this command. Unless given `--quiet`, foreach prints the name
> +of each submodule before evaluating the command.
> +If `--recursive` is given, submodules are traversed recursively (i.e.
> +the given shell command is evaluated in nested submodules as well).
> +A non-zero return from the command in any submodule causes
> +the processing to terminate. This can be overridden by adding ++||:++
> +to the end of the command.
>  +
>  As an example, the command below will show the path and currently
>  checked out commit for each submodule:
> @@ -249,10 +253,10 @@ checked out commit for each submodule:
>  git submodule foreach 'echo $sm_path `git rev-parse HEAD`'
>  --------------

Good.

>
> -sync [--recursive] [--] [<path>...]::
> -	Synchronizes submodules' remote URL configuration setting
> +`sync [--recursive] [--] [<path>...]`::
> +	Synchronize submodules' remote URL configuration setting
>  	to the value specified in `.gitmodules`. It will only affect those
> -	submodules which already have a URL entry in .git/config (that is the
> +	submodules which already have a URL entry in `.git/config` (that is the
>  	case when they are initialized or freshly added). This is useful when
>  	submodule URLs change upstream and you need to update your local
>  	repositories accordingly.

Good.

There is also a "A" that you might want to change to `A`.

> @@ -263,12 +267,12 @@ sync [--recursive] [--] [<path>...]::
>  If `--recursive` is specified, this command will recurse into the
>  registered submodules, and sync any nested submodules within.
>
> -absorbgitdirs::
> +`absorbgitdirs`::
>  	If a git directory of a submodule is inside the submodule,
>  	move the git directory of the submodule into its superproject's
>  	`$GIT_DIR/modules` path and then connect the git directory and
>  	its working directory by setting the `core.worktree` and adding
> -	a .git file pointing to the git directory embedded in the
> +	a `.git` file pointing to the git directory embedded in the
>  	superprojects git directory.
>  +
>  A repository that was cloned independently and later added as a submodule or
> @@ -279,72 +283,70 @@ This command is recursive by default.
>
>  OPTIONS
>  -------
> --q::
> ---quiet::
> +`-q`::
> +`--quiet`::
>  	Only print error messages.
>
> ---progress::
> -	This option is only valid for add and update commands.
> -	Progress status is reported on the standard error stream
> -	by default when it is attached to a terminal, unless -q
> +`--progress`::
> +	Report progress status on the standard error stream
> +	by default when it is attached to a terminal, unless `-q`
>  	is specified. This flag forces progress status even if the
> -	standard error stream is not directed to a terminal.
> +	standard error stream is not directed to a terminal. It is
> +	only valid for `add` and `update` commands.
>
> ---all::
> -	This option is only valid for the deinit command. Unregister all
> -	submodules in the working tree.
> +`--all`::
> +	Unregister all submodules in the working tree. This option is only
> +	valid for the `deinit` command.
>
> --b <branch>::
> ---branch <branch>::
> +`-b <branch>`::
> +`--branch <branch>`::
>  	Branch of repository to add as submodule.
>  	The name of the branch is recorded as `submodule.<name>.branch` in
>  	`.gitmodules` for `update --remote`.  A special value of `.` is used to
>  	indicate that the name of the branch in the submodule should be the
>  	same name as the current branch in the current repository.  If the
> -	option is not specified, it defaults to the remote 'HEAD'.
> -
> --f::
> ---force::
> -	This option is only valid for add, deinit and update commands.
> -	When running add, allow adding an otherwise ignored submodule path.
> -	This option is also used to bypass a check that the submodule's name
> -	is not already in use. By default, 'git submodule add' will fail if
> -	the proposed name (which is derived from the path) is already registered
> -	for another submodule in the repository. Using '--force' allows the command
> -	to proceed by automatically generating a unique name by appending a number
> -	to the conflicting name (e.g., if a submodule named 'child' exists, it will
> -	try 'child1', and so on).
> -	When running deinit the submodule working trees will be removed even
> -	if they contain local changes.
> -	When running update (only effective with the checkout procedure),
> -	throw away local changes in submodules when switching to a
> -	different commit; and always run a checkout operation in the
> -	submodule, even if the commit listed in the index of the
> -	containing repository matches the commit checked out in the
> -	submodule.
> -
> ---cached::
> -	This option is only valid for status and summary commands.  These
> -	commands typically use the commit found in the submodule HEAD, but
> -	with this option, the commit stored in the index is used instead.
> -
> ---files::
> -	This option is only valid for the summary command. This command
> -	compares the commit in the index with that in the submodule HEAD
> -	when this option is used.
> -
> --n::
> ---summary-limit::
> -	This option is only valid for the summary command.
> -	Limit the summary size (number of commits shown in total).
> +	option is not specified, it defaults to the remote `HEAD`.
> +
> +`-f`::
> +`--force`::
> +	Force the command to proceed, even if it would otherwise fail.
> +	This option is only valid for `add`, `deinit` and `update` commands.
> +`add`;; allow adding an otherwise ignored submodule path.
> +This option is also used to bypass a check that the submodule's name
> +is not already in use. By default, `git submodule add` will fail if
> +the proposed name (which is derived from the path) is already registered
> +for another submodule in the repository. Using `--force` allows the command
> +to proceed by automatically generating a unique name by appending a number
> +to the conflicting name (e.g., if a submodule named 'child' exists, it will
> +try 'child1', and so on).
> +`deinit`;; the submodule working trees will be removed even
> +if they contain local changes.
> +`update`;; (only effective with the checkout procedure),
> +throw away local changes in submodules when switching to a
> +different commit; and always run a checkout operation in the
> +submodule, even if the commit listed in the index of the
> +containing repository matches the commit checked out in the
> +submodule.
> +
> +`--cached`::
> +	Use the index to determine the commit instead of the `HEAD`.
> +	This option is only valid for `status` and `summary` commands.
> +
> +`--files`::
> +	Make the `summary` command compare the commit in the index with that in
> +	the submodule `HEAD`.
> +
> +`-n <n>`::
> +`--summary-limit <n>`::
> +	Limit the `summary` size (number of commits shown in total) to _<n>_.
>  	Giving 0 will disable the summary; a negative number means unlimited
>  	(the default). This limit only applies to modified submodules. The
>  	size is always limited to 1 for added/deleted/typechanged submodules.
>
> ---remote::
> -	This option is only valid for the update command.  Instead of using
> -	the superproject's recorded SHA-1 to update the submodule, use the
> -	status of the submodule's remote-tracking branch.  The remote used
> +`--remote`::
> +	Instead of using the superproject's recorded SHA-1 to update the
> +	submodule, use the status of the submodule's remote-tracking branch.
> +	This option is only valid for the `update` command. The remote used
>  	is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
>  	The remote branch used defaults to the remote `HEAD`, but the branch
>  	name may be overridden by setting the `submodule.<name>.branch`
> @@ -363,7 +365,7 @@ SHA-1.  If you don't want to fetch, you should use
> `submodule update
>  --remote --no-fetch`.
>  +
>  Use this option to integrate changes from the upstream subproject with
> -your submodule's current HEAD.  Alternatively, you can run `git pull`
> +your submodule's current `HEAD`.  Alternatively, you can run `git pull`
>  from the submodule, which is equivalent except for the remote branch
>  name: `update --remote` uses the default upstream repository and
>  `submodule.<name>.branch`, while `git pull` uses the submodule's
> @@ -372,51 +374,51 @@ to distribute the default upstream branch with
> the superproject and
>  `branch.<name>.merge` if you want a more native feel while working in
>  the submodule itself.
>
> --N::
> ---no-fetch::
> -	This option is only valid for the update command.
> +`-N`::
> +`--no-fetch`::
>  	Don't fetch new objects from the remote site.
> +	This option is only valid for the `update` command.
>
> ---checkout::
> -	This option is only valid for the update command.
> -	Checkout the commit recorded in the superproject on a detached HEAD
> +`--checkout`::
> +	This option is only valid for the `update` command.
> +	Checkout the commit recorded in the superproject on a detached `HEAD`
>  	in the submodule. This is the default behavior, the main use of
> -	this option is to override `submodule.$name.update` when set to
> +	this option is to override `submodule.<name>.update` when set to
>  	a value other than `checkout`.
> -	If the key `submodule.$name.update` is either not explicitly set or
> +	If the key `submodule.<name>.update` is either not explicitly set or
>  	set to `checkout`, this option is implicit.
>
> ---merge::
> -	This option is only valid for the update command.
> +`--merge`::
>  	Merge the commit recorded in the superproject into the current branch
> -	of the submodule. If this option is given, the submodule's HEAD will
> +	of the submodule. This option is only valid for the `update` command.
> +	If this option is given, the submodule's `HEAD` will
>  	not be detached. If a merge failure prevents this process, you will
>  	have to resolve the resulting conflicts within the submodule with the
>  	usual conflict resolution tools.
> -	If the key `submodule.$name.update` is set to `merge`, this option is
> +	If the key `submodule.<name>.update` is set to `merge`, this option is
>  	implicit.
>
> ---rebase::
> +`--rebase`::
>  	This option is only valid for the update command.
>  	Rebase the current branch onto the commit recorded in the
>  	superproject. If this option is given, the submodule's HEAD will not
>  	be detached. If a merge failure prevents this process, you will have
>  	to resolve these failures with linkgit:git-rebase[1].
> -	If the key `submodule.$name.update` is set to `rebase`, this option is
> +	If the key `submodule.<name>.update` is set to `rebase`, this option is
>  	implicit.
>
> ---init::
> -	This option is only valid for the update command.
> -	Initialize all submodules for which "git submodule init" has not been
> -	called so far before updating.
> +`--init`::
> +	Initialize all submodules for which `git submodule init` has not been
> +	called so far before updating. 	This option is only valid for the `update`
> +	command.
> +
>
> ---name::
> -	This option is only valid for the add command. It sets the submodule's
> -	name to the given string instead of defaulting to its path. The name
> +`--name <name>`::
> +	Set the submodule's name to the given string instead of defaulting to
> its path. _<name>_
>  	must be valid as a directory name and may not end with a '/'.
>
> ---reference <repository>::
> -	This option is only valid for add and update commands.  These
> +`--reference <repository>`::
> +	This option is only valid for `add` and `update` commands.  These
>  	commands sometimes need to clone a remote repository. In this case,
>  	this option will be passed to the linkgit:git-clone[1] command.
>  +
> @@ -424,53 +426,52 @@ the submodule itself.
>  for linkgit:git-clone[1]'s `--reference`, `--shared`, and `--dissociate`
>  options carefully.
>
> ---dissociate::
> +`--dissociate`::
>  	This option is only valid for add and update commands.  These
>  	commands sometimes need to clone a remote repository. In this case,
>  	this option will be passed to the linkgit:git-clone[1] command.
>  +
> -*NOTE*: see the NOTE for the `--reference` option.
> +*NOTE*: see the NOTE above for the `--reference` option.

Asciidoc NOTE macro here?

See also that NOTE:

    *NOTE*: Do *not* use this option unless you have read the note
    for linkgit:git-clone[1]'s `--reference`, `--shared`, and `--dissociate`
    options carefully.

    `--dissociate`::
            This option is only valid for add and update commands.  These
            commands sometimes need to clone a remote repository. In this case,
            this option will be passed to the linkgit:git-clone[1] command.
    +
    *NOTE*: see the NOTE above for the `--reference` option.

>
> ---recursive::
> -	This option is only valid for foreach, update, status and sync commands.
> -	Traverse submodules recursively. The operation is performed not
> +`--recursive`::
> +	Traverse submodules recursively. This option is only valid for `foreach`,
> +	`update`, `status` and `sync` commands. The operation is performed not
>  	only in the submodules of the current repo, but also
>  	in any nested submodules inside those submodules (and so on).
>
> ---depth::
> -	This option is valid for add and update commands. Create a 'shallow'
> -	clone with a history truncated to the specified number of revisions.
> -	See linkgit:git-clone[1]
> +`--depth <depth>`::
> +	Create a 'shallow' clone with a history truncated to the _<depth>_ revisions.
> +	This option is valid for `add` and `update` commands. See linkgit:git-clone[1]
>
> ---recommend-shallow::
> ---no-recommend-shallow::
> -	This option is only valid for the update command.
> +`--recommend-shallow`::
> +`--no-recommend-shallow`::
> +	This option is only valid for the `update` command.
>  	The initial clone of a submodule will use the recommended
>  	`submodule.<name>.shallow` as provided by the `.gitmodules` file
>  	by default. To ignore the suggestions use `--no-recommend-shallow`.
>
> --j <n>::
> ---jobs <n>::
> -	This option is only valid for the update command.
> -	Clone new submodules in parallel with as many jobs.
> +`-j <n>`::
> +`--jobs <n>`::
> +	Clone new submodules in parallel with _<n>_ jobs.
> +	This option is only valid for the `update` command.
>  	Defaults to the `submodule.fetchJobs` option.
>
> ---single-branch::
> ---no-single-branch::
> -	This option is only valid for the update command.
> -	Clone only one branch during update: HEAD or one specified by --branch.
> +`--single-branch`::
> +`--no-single-branch`::
> +	Clone only one branch during update: `HEAD` or one specified by `--branch`.
> +	This option is only valid for the `update` command.
>
> -<path>...::
> +`<path>...`::
>  	Paths to submodule(s). When specified this will restrict the command
>  	to only operate on the submodules found at the specified paths.
> -	(This argument is required with add).
> +	(This argument is required with `add`).
>
>  FILES
>  -----
>  When initializing submodules, a `.gitmodules` file in the top-level directory
> -of the containing repository is used to find the url of each submodule.
> +of the containing repository is used to find the URL of each submodule.
>  This file should be formatted in the same way as `$GIT_DIR/config`. The key
> -to each submodule url is "submodule.$name.url".  See linkgit:gitmodules[5]
> +to each submodule URL is `submodule.<name>.url`.  See linkgit:gitmodules[5]
>  for details.

Looks good.

>
>  SEE ALSO
> --
> gitgitgadget

  reply	other threads:[~2026-02-01 12:04 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23 21:14 [PATCH 0/4] doc: some more synopsis conversions and fixes Jean-Noël Avila via GitGitGadget
2026-01-23 21:15 ` [PATCH 1/4] convert git-submodule doc to synopsis style Jean-Noël Avila via GitGitGadget
2026-02-01 12:04   ` Kristoffer Haugsbakk [this message]
2026-01-23 21:15 ` [PATCH 2/4] doc: finalize git-clone documentation conversion " Jean-Noël Avila via GitGitGadget
2026-02-01 12:04   ` Kristoffer Haugsbakk
2026-02-01 13:14     ` Jean-Noël AVILA
2026-02-02  8:36       ` Kristoffer Haugsbakk
2026-01-23 21:15 ` [PATCH 3/4] doc: fix some style issues in git-clone and for-each-ref-options Jean-Noël Avila via GitGitGadget
2026-02-01 12:11   ` Kristoffer Haugsbakk
2026-01-23 21:15 ` [PATCH 4/4] doc: convert git-show to synopsis style Jean-Noël Avila via GitGitGadget
2026-01-25 19:27   ` Kristoffer Haugsbakk
2026-01-25 21:11     ` Jean-Noël AVILA
2026-01-26  5:58       ` Kristoffer Haugsbakk
2026-01-26 21:25 ` [PATCH v2 0/4] doc: some more synopsis conversions and fixes Jean-Noël Avila via GitGitGadget
2026-01-26 21:25   ` [PATCH v2 1/4] convert git-submodule doc to synopsis style Jean-Noël Avila via GitGitGadget
2026-01-26 21:25   ` [PATCH v2 2/4] doc: finalize git-clone documentation conversion " Jean-Noël Avila via GitGitGadget
2026-01-26 21:25   ` [PATCH v2 3/4] doc: fix some style issues in git-clone and for-each-ref-options Jean-Noël Avila via GitGitGadget
2026-01-26 21:25   ` [PATCH v2 4/4] doc: convert git-show to synopsis style Jean-Noël Avila via GitGitGadget
2026-02-01 12:12     ` Kristoffer Haugsbakk
2026-02-01 16:39       ` Jean-Noël AVILA
2026-02-03 17:03   ` [PATCH v3 0/4] doc: some more synopsis conversions and fixes Jean-Noël Avila via GitGitGadget
2026-02-03 17:03     ` [PATCH v3 1/4] doc: convert git-submodule to synopsis style Jean-Noël Avila via GitGitGadget
2026-02-03 21:45       ` Kristoffer Haugsbakk
2026-02-06  3:55         ` Jean-Noël Avila
2026-02-03 17:03     ` [PATCH v3 2/4] doc: finalize git-clone documentation conversion " Jean-Noël Avila via GitGitGadget
2026-02-03 21:45       ` Kristoffer Haugsbakk
2026-02-03 17:03     ` [PATCH v3 3/4] doc: fix some style issues in git-clone and for-each-ref-options Jean-Noël Avila via GitGitGadget
2026-02-03 21:46       ` Kristoffer Haugsbakk
2026-02-03 17:03     ` [PATCH v3 4/4] doc: convert git-show to synopsis style Jean-Noël Avila via GitGitGadget
2026-02-03 21:44       ` Kristoffer Haugsbakk
2026-02-03 21:44     ` [PATCH v3 0/4] doc: some more synopsis conversions and fixes Kristoffer Haugsbakk
2026-02-04 16:24       ` Kristoffer Haugsbakk
2026-02-06  4:12     ` [PATCH v4 " Jean-Noël Avila via GitGitGadget
2026-02-06  4:12       ` [PATCH v4 1/4] doc: convert git-submodule to synopsis style Jean-Noël Avila via GitGitGadget
2026-02-06  4:12       ` [PATCH v4 2/4] doc: finalize git-clone documentation conversion " Jean-Noël Avila via GitGitGadget
2026-02-06  4:12       ` [PATCH v4 3/4] doc: fix some style issues in git-clone and for-each-ref-options Jean-Noël Avila via GitGitGadget
2026-02-06  4:12       ` [PATCH v4 4/4] doc: convert git-show to synopsis style Jean-Noël Avila via GitGitGadget
2026-02-07 14:24       ` [PATCH v4 0/4] doc: some more synopsis conversions and fixes Kristoffer Haugsbakk

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=83cef072-530a-423b-ba89-26eb6bc63e67@app.fastmail.com \
    --to=kristofferhaugsbakk@fastmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jn.avila@free.fr \
    /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