repository, the presumption is the superproject and
submodule repositories will be kept together in the same relative
location, and only the superproject's URL needs to be provided.
git-submodule will correctly locate the submodule using the relative
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>...]::
	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
	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
	repository and `U` if the submodule has merge conflicts.
+
If `--cached` is specified, this command will instead print the SHA-1
recorded in the superproject for each submodule.
+
If `--recursive` is specified, this command will recurse into nested
submodules, and show their status as well.
+
If you are only interested in changes of the currently initialized
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>...]::
	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
	a template. If the URL is relative, it will be resolved using
	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.
If no path is specified and submodule.active has been configured, submodules
configured to be active will be initialized, otherwise all submodules are
initialized.
+
It will also copy the value of `submodule.$name.update`, if present in
the `.gitmodules` file, to `.git/config`, but (1) this command does not
alter existing information in `.git/config`, and (2) `submodule.$name.update`
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
any submodule locations.
+
See the add subcommand for the definition of default remote.

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`
	and `git submodule sync` will skip any unregistered submodules until
	they are initialized again, so use this command if you don't want to
	have a local checkout of the submodule in your working tree anymore.
+
When the command is run without pathspec, it errors out,
instead of deinit-ing everything, to prevent mistakes.
+
If `--force` is specified, the submodule's working tree will
be removed even if it contains local modifications.
+
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.

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
expects by cloning missing submodules, fetching missing commits
in submodules and updating the working tree of
the submodules. The "updating" can be done