submodule

submodule.<name>.url
The URL for a submodule. This variable is copied from the .gitmodules file to the git config via ’git submodule init’. The user can change the configured URL before obtaining the submodule via ’git submodule update’. If neither submodule.<name>.active nor submodule.active are set, the presence of this variable is used as a fallback to indicate whether the submodule is of interest to git commands. See linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.

submodule.<name>.update
The method by which a submodule is updated by ’git submodule update’, which is the only affected command, others such as ’git checkout --recurse-submodules’ are unaffected. It exists for historical reasons, when ’git submodule’ was the only command to interact with submodules; settings like submodule.active and pull.rebase are more specific. It is populated by git submodule init from the linkgit:gitmodules[5] file. See description of ’update’ command in linkgit:git-submodule[1].

submodule.<name>.branch
The remote branch name for a submodule, used by git submodule update --remote. Set this option to override the value found in the .gitmodules file. See linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.

submodule.<name>.fetchRecurseSubmodules
This option can be used to control recursive fetching of this submodule. It can be overridden by using the --[no-]recurse-submodules command-line option to "git fetch" and "git pull". This setting will override that from in the linkgit:gitmodules[5] file.

submodule.<name>.ignore
Defines under what circumstances "git status" and the diff family show a submodule as modified. When set to "all" will never consider the submodule modified. It can nevertheless be staged using the option --force and it will then show up in the output of status. When set to "dirty" will ignore all changes to the submodule’s work tree and takes only differences between the HEAD of the submodule and the commit recorded in the superproject into account. "untracked" will additionally let submodules with modified tracked files in their work tree show up. When set to "none" (default) it also shows submodules as changed if they have untracked files in their work tree. This setting overrides any setting made in .gitmodules for this submodule, both settings can be overridden on the command line by using the "--ignore-submodules" option. The ’git submodule’ commands are not affected by this setting.

submodule.<name>.active
Boolean value indicating if the submodule is of interest to git commands. This config option takes precedence over the submodule.active config option. See linkgit:gitsubmodules[7] for details.

submodule.<name>.gitdir
This sets the gitdir path for submodule <name>. This configuration is respected when extensions.submodulePathConfig is enabled, otherwise it has no effect. When enabled, this config becomes the single source of truth for submodule gitdir paths and Git will error if it is missing. See linkgit:git-config[1] for details.

submodule.active
A repeated field which contains a pathspec used to match against a submodule’s path to determine if the submodule is of interest to git commands. See linkgit:gitsubmodules[7] for details.

submodule.recurse
A boolean indicating if commands should enable the --recurse-submodules option by default. Defaults to false.

When set to true, it can be deactivated via the --no-recurse-submodules option. Note that some Git commands lacking this option may call some of the above commands affected by submodule.recurse; for instance git remote update will call git fetch but does not have a --no-recurse-submodules option. For these commands a workaround is to temporarily change the configuration value by using git -c submodule.recurse=0.

The following list shows the commands that accept --recurse-submodules and whether they are supported by this setting.

• checkout, fetch, grep, pull, push, read-tree, reset, restore and switch are always supported.

• clone and ls-files are not supported.

• branch is supported only if submodule.propagateBranches is enabled

submodule.propagateBranches
[EXPERIMENTAL] A boolean that enables branching support when using --recurse-submodules or submodule.recurse=true. Enabling this will allow certain commands to accept --recurse-submodules and certain commands that already accept --recurse-submodules will now consider branches. Defaults to false.

submodule.fetchJobs
Specifies how many submodules are fetched/cloned at the same time. A positive integer allows up to that number of submodules fetched in parallel. A value of 0 will give some reasonable default. If unset, it defaults to 1.

submodule.alternateLocation
Specifies how the submodules obtain alternates when submodules are cloned. Possible values are no, superproject. By default no is assumed, which doesn’t add references. When the value is set to superproject the submodule to be cloned computes its alternates location relative to the superprojects alternate.

submodule.alternateErrorStrategy
Specifies how to treat errors with the alternates for a submodule as computed via submodule.alternateLocation. Possible values are ignore, info, die. Default is die. Note that if set to ignore or info, and if there is an error with the computed alternate, the clone proceeds as if no alternate was specified.