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 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.
(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
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.
+
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.
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.
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
submodule with the `--init` option.
If `--recursive` is specified, this command will recurse into the
registered submodules, and update any nested submodules within.
If `--ref-format <format>` is specified, the ref storage format of newly
cloned submodules will be set accordingly.
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
`--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'.
set-url [--] <path> <newurl>::
Sets 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
working tree/index. For a submodule