| 1 | git-submodule(1) |
| 2 | ================ |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | git-submodule - Initialize, update or inspect submodules |
| 7 | |
| 8 | |
| 9 | SYNOPSIS |
| 10 | -------- |
| 11 | [synopsis] |
| 12 | git submodule [--quiet] [--cached] |
| 13 | git submodule [--quiet] add [<options>] [--] <repository> [<path>] |
| 14 | git submodule [--quiet] status [--cached] [--recursive] [--] [<path>...] |
| 15 | git submodule [--quiet] init [--] [<path>...] |
| 16 | git submodule [--quiet] deinit [-f|--force] (--all|[--] <path>...) |
| 17 | git submodule [--quiet] update [<options>] [--] [<path>...] |
| 18 | git submodule [--quiet] set-branch [<options>] [--] <path> |
| 19 | git submodule [--quiet] set-url [--] <path> <newurl> |
| 20 | git submodule [--quiet] summary [<options>] [--] [<path>...] |
| 21 | git submodule [--quiet] foreach [--recursive] <command> |
| 22 | git submodule [--quiet] sync [--recursive] [--] [<path>...] |
| 23 | git submodule [--quiet] absorbgitdirs [--] [<path>...] |
| 24 | |
| 25 | |
| 26 | DESCRIPTION |
| 27 | ----------- |
| 28 | Inspects, updates and manages submodules. |
| 29 | |
| 30 | For more information about submodules, see linkgit:gitsubmodules[7]. |
| 31 | |
| 32 | COMMANDS |
| 33 | -------- |
| 34 | With no arguments, shows the status of existing submodules. Several |
| 35 | subcommands are available to perform operations on the submodules. |
| 36 | |
| 37 | `add [-b <branch>] [-f | --force] [--name <name>] [--reference <repository>] [--ref-format <format>] [--depth <depth>] [--] <repository> [<path>]`:: |
| 38 | Add the given repository as a submodule at the given path |
| 39 | to the changeset to be committed next to the current |
| 40 | project: the current project is termed the "superproject". |
| 41 | + |
| 42 | _<repository>_ is the URL of the new submodule's `origin` repository. |
| 43 | This may be either an absolute URL, or (if it begins with `./` |
| 44 | or `../`), the location relative to the superproject's default remote |
| 45 | repository (Please note that to specify a repository `foo.git` |
| 46 | which is located right next to a superproject `bar.git`, you'll |
| 47 | have to use `../foo.git` instead of `./foo.git` - as one might expect |
| 48 | when following the rules for relative URLs - because the evaluation |
| 49 | of relative URLs in Git is identical to that of relative directories). |
| 50 | + |
| 51 | The default remote is the remote of the remote-tracking branch |
| 52 | of the current branch. If no such remote-tracking branch exists or |
| 53 | the `HEAD` is detached, `origin` is assumed to be the default remote. |
| 54 | If the superproject doesn't have a default remote configured |
| 55 | the superproject is its own authoritative upstream and the current |
| 56 | working directory is used instead. |
| 57 | + |
| 58 | The optional argument _<path>_ is the relative location for the cloned |
| 59 | submodule to exist in the superproject. If _<path>_ is not given, the |
| 60 | canonical part of the source repository is used (`repo` for |
| 61 | `/path/to/repo.git` and `foo` for `host.xz:foo/.git`). If _<path>_ |
| 62 | exists and is already a valid Git repository, then it is staged |
| 63 | for commit without cloning. The _<path>_ is also used as the submodule's |
| 64 | logical name in its configuration entries unless `--name <name>` is used |
| 65 | to specify a logical name. |
| 66 | + |
| 67 | The given URL is recorded into `.gitmodules` for use by subsequent users |
| 68 | cloning the superproject. If the URL is given relative to the |
| 69 | superproject's repository, the presumption is the superproject and |
| 70 | submodule repositories will be kept together in the same relative |
| 71 | location, and only the superproject's URL needs to be provided. |
| 72 | git-submodule will correctly locate the submodule using the relative |
| 73 | URL in `.gitmodules`. |
| 74 | + |
| 75 | If `--ref-format <format>` is specified, the ref storage format of newly |
| 76 | cloned submodules will be set accordingly. |
| 77 | |
| 78 | `status [--cached] [--recursive] [--] [<path>...]`:: |
| 79 | Show the status of the submodules. This will print the SHA-1 of the |
| 80 | currently checked out commit for each submodule, along with the |
| 81 | submodule path and the output of linkgit:git-describe[1] for the |
| 82 | SHA-1. Each SHA-1 will possibly be prefixed with `-` if the submodule is |
| 83 | not initialized, `+` if the currently checked out submodule commit |
| 84 | does not match the SHA-1 found in the index of the containing |
| 85 | repository and `U` if the submodule has merge conflicts. |
| 86 | + |
| 87 | If `--cached` is specified, this command will instead print the SHA-1 |
| 88 | recorded in the superproject for each submodule. |
| 89 | + |
| 90 | If `--recursive` is specified, this command will recurse into nested |
| 91 | submodules, and show their status as well. |
| 92 | + |
| 93 | If you are only interested in changes of the currently initialized |
| 94 | submodules with respect to the commit recorded in the index or the `HEAD`, |
| 95 | linkgit:git-status[1] and linkgit:git-diff[1] will provide that information |
| 96 | too (and can also report changes to a submodule's work tree). |
| 97 | |
| 98 | `init [--] [<path>...]`:: |
| 99 | Initialize the submodules recorded in the index (which were |
| 100 | added and committed elsewhere) by setting `submodule.$name.url` |
| 101 | in `.git/config`, using the same setting from `.gitmodules` as |
| 102 | a template. If the URL is relative, it will be resolved using |
| 103 | the default remote. If there is no default remote, the current |
| 104 | repository will be assumed to be upstream. |
| 105 | + |
| 106 | Optional _<path>_ arguments limit which submodules will be initialized. |
| 107 | If no path is specified and submodule.active has been configured, submodules |
| 108 | configured to be active will be initialized, otherwise all submodules are |
| 109 | initialized. |
| 110 | + |
| 111 | It will also copy the value of `submodule.$name.update`, if present in |
| 112 | the `.gitmodules` file, to `.git/config`, but (1) this command does not |
| 113 | alter existing information in `.git/config`, and (2) `submodule.$name.update` |
| 114 | that is set to a custom command is *not* copied for security reasons. |
| 115 | + |
| 116 | You can then customize the submodule clone URLs in `.git/config` |
| 117 | for your local setup and proceed to `git submodule update`; |
| 118 | you can also just use `git submodule update --init` without |
| 119 | the explicit `init` step if you do not intend to customize |
| 120 | any submodule locations. |
| 121 | + |
| 122 | See the add subcommand for the definition of default remote. |
| 123 | |
| 124 | `deinit [-f | --force] (--all|[--] <path>...)`:: |
| 125 | Unregister the given submodules, i.e. remove the whole |
| 126 | `submodule.$name` section from .git/config together with their work |
| 127 | tree. Further calls to `git submodule update`, `git submodule foreach` |
| 128 | and `git submodule sync` will skip any unregistered submodules until |
| 129 | they are initialized again, so use this command if you don't want to |
| 130 | have a local checkout of the submodule in your working tree anymore. |
| 131 | + |
| 132 | When the command is run without pathspec, it errors out, |
| 133 | instead of deinit-ing everything, to prevent mistakes. |
| 134 | + |
| 135 | If `--force` is specified, the submodule's working tree will |
| 136 | be removed even if it contains local modifications. |
| 137 | + |
| 138 | If you really want to remove a submodule from the repository and commit |
| 139 | that use linkgit:git-rm[1] instead. See linkgit:gitsubmodules[7] for removal |
| 140 | options. |
| 141 | |
| 142 | `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>...]`:: |
| 143 | + |
| 144 | -- |
| 145 | Update the registered submodules to match what the superproject |
| 146 | expects by cloning missing submodules, fetching missing commits |
| 147 | in submodules and updating the working tree of |
| 148 | the submodules. The "updating" can be done in several ways depending |
| 149 | on command line options and the value of `submodule.<name>.update` |
| 150 | configuration variable. The command line option takes precedence over |
| 151 | the configuration variable. If neither is given, a `checkout` is performed. |
| 152 | (note: what is in `.gitmodules` file is irrelevant at this point; |
| 153 | see `git submodule init` above for how `.gitmodules` is used). |
| 154 | The `update` procedures supported both from the command line as well as |
| 155 | through the `submodule.<name>.update` configuration are: |
| 156 | |
| 157 | `checkout`;; the commit recorded in the superproject will be |
| 158 | checked out in the submodule on a detached `HEAD`. |
| 159 | + |
| 160 | If `--force` is specified, the submodule will be checked out (using |
| 161 | `git checkout --force`), even if the commit specified |
| 162 | in the index of the containing repository already matches the commit |
| 163 | checked out in the submodule. |
| 164 | |
| 165 | `rebase`;; the current branch of the submodule will be rebased |
| 166 | onto the commit recorded in the superproject. |
| 167 | |
| 168 | `merge`;; the commit recorded in the superproject will be merged |
| 169 | into the current branch in the submodule. |
| 170 | |
| 171 | The following update procedures have additional limitations: |
| 172 | |
| 173 | `!<custom-command>`;; mechanism for running arbitrary commands with the |
| 174 | commit ID as an argument. Specifically, if the |
| 175 | `submodule.<name>.update` configuration variable is set to |
| 176 | `!<custom-command>`, the object name of the commit recorded in the |
| 177 | superproject for the submodule is appended to the _<custom-command>_ |
| 178 | string and executed. Note that this mechanism is not supported in |
| 179 | the `.gitmodules` file or on the command line. |
| 180 | |
| 181 | `none`;; the submodule is not updated. This update procedure is not |
| 182 | allowed on the command line. |
| 183 | |
| 184 | If the submodule is not yet initialized, and you just want to use the |
| 185 | setting as stored in `.gitmodules`, you can automatically initialize the |
| 186 | submodule with the `--init` option. |
| 187 | |
| 188 | If `--recursive` is specified, this command will recurse into the |
| 189 | registered submodules, and update any nested submodules within. |
| 190 | |
| 191 | If `--ref-format <format>` is specified, the ref storage format of newly |
| 192 | cloned submodules will be set accordingly. |
| 193 | |
| 194 | If `--filter <filter-spec>` is specified, the given partial clone filter will be |
| 195 | applied to the submodule. See linkgit:git-rev-list[1] for details on filter |
| 196 | specifications. |
| 197 | -- |
| 198 | `set-branch (-b|--branch) <branch> [--] <path>`:: |
| 199 | `set-branch (-d|--default) [--] <path>`:: |
| 200 | Set the default remote tracking branch for the submodule. The |
| 201 | `--branch` option allows the remote branch to be specified. The |
| 202 | `--default` option removes the `submodule.<name>.branch` configuration |
| 203 | key, which causes the tracking branch to default to the remote `HEAD`. |
| 204 | |
| 205 | `set-url [--] <path> <newurl>`:: |
| 206 | Set the URL of the specified submodule to _<newurl>_. Then, it will |
| 207 | automatically synchronize the submodule's new remote URL |
| 208 | configuration. |
| 209 | |
| 210 | `summary [--cached | --files] [(-n|--summary-limit) <n>] [commit] [--] [<path>...]`:: |
| 211 | Show commit summary between the given commit (defaults to `HEAD`) and |
| 212 | working tree/index. For a submodule in question, a series of commits |
| 213 | in the submodule between the given super project commit and the |
| 214 | index or working tree (switched by `--cached`) are shown. If the option |
| 215 | `--files` is given, show the series of commits in the submodule between |
| 216 | the index of the super project and the working tree of the submodule |
| 217 | (this option doesn't allow to use the `--cached` option or to provide an |
| 218 | explicit commit). |
| 219 | + |
| 220 | Using the `--submodule=log` option with linkgit:git-diff[1] will provide that |
| 221 | information too. |
| 222 | |
| 223 | `foreach [--recursive] <command>`:: |
| 224 | Evaluate an arbitrary shell _<command>_ in each checked out submodule. |
| 225 | The command has access to the variables `$name`, `$sm_path`, `$displaypath`, |
| 226 | `$sha1` and `$toplevel`: |
| 227 | + |
| 228 | -- |
| 229 | `$name`;; the name of the relevant submodule section in `.gitmodules` |
| 230 | `$sm_path`;; the path of the submodule as recorded in the immediate |
| 231 | superproject |
| 232 | `$displaypath`;; the relative path from the |
| 233 | current working directory to the submodules root directory |
| 234 | `$sha1`;; the commit as recorded in the immediate superproject |
| 235 | `$toplevel`;; the absolute path to the top-level of the immediate superproject. |
| 236 | -- |
| 237 | + |
| 238 | Note that to avoid conflicts with `$PATH` on Windows, the `$path` |
| 239 | variable is now a deprecated synonym of `$sm_path` variable. |
| 240 | Any submodules defined in the superproject but not checked out are |
| 241 | ignored by this command. Unless given `--quiet`, foreach prints the name |
| 242 | of each submodule before evaluating the command. |
| 243 | If `--recursive` is given, submodules are traversed recursively (i.e. |
| 244 | the given shell command is evaluated in nested submodules as well). |
| 245 | A non-zero return from the command in any submodule causes |
| 246 | the processing to terminate. This can be overridden by adding ++||:++ |
| 247 | to the end of the command. |
| 248 | + |
| 249 | As an example, the command below will show the path and currently |
| 250 | checked out commit for each submodule: |
| 251 | + |
| 252 | -------------- |
| 253 | git submodule foreach 'echo $sm_path `git rev-parse HEAD`' |
| 254 | -------------- |
| 255 | |
| 256 | `sync [--recursive] [--] [<path>...]`:: |
| 257 | Synchronize submodules' remote URL configuration setting |
| 258 | to the value specified in `.gitmodules`. It will only affect those |
| 259 | submodules which already have a URL entry in `.git/config` (that is the |
| 260 | case when they are initialized or freshly added). This is useful when |
| 261 | submodule URLs change upstream and you need to update your local |
| 262 | repositories accordingly. |
| 263 | + |
| 264 | `git submodule sync` synchronizes all submodules while |
| 265 | `git submodule sync -- A` synchronizes submodule `A` only. |
| 266 | + |
| 267 | If `--recursive` is specified, this command will recurse into the |
| 268 | registered submodules, and sync any nested submodules within. |
| 269 | |
| 270 | `absorbgitdirs`:: |
| 271 | If a git directory of a submodule is inside the submodule, |
| 272 | move the git directory of the submodule into its superproject's |
| 273 | `$GIT_DIR/modules` path and then connect the git directory and |
| 274 | its working directory by setting the `core.worktree` and adding |
| 275 | a `.git` file pointing to the git directory embedded in the |
| 276 | superprojects git directory. |
| 277 | + |
| 278 | A repository that was cloned independently and later added as a submodule or |
| 279 | old setups have the submodules git directory inside the submodule instead of |
| 280 | embedded into the superprojects git directory. |
| 281 | + |
| 282 | This command is recursive by default. |
| 283 | |
| 284 | OPTIONS |
| 285 | ------- |
| 286 | `-q`:: |
| 287 | `--quiet`:: |
| 288 | Only print error messages. |
| 289 | |
| 290 | `--progress`:: |
| 291 | Report progress status on the standard error stream |
| 292 | by default when it is attached to a terminal, unless `-q` |
| 293 | is specified. This flag forces progress status even if the |
| 294 | standard error stream is not directed to a terminal. It is |
| 295 | only valid for `add` and `update` commands. |
| 296 | |
| 297 | `--all`:: |
| 298 | Unregister all submodules in the working tree. This option is only |
| 299 | valid for the `deinit` command. |
| 300 | |
| 301 | `-b<branch>`:: |
| 302 | `--branch=<branch>`:: |
| 303 | Branch of repository to add as submodule. |
| 304 | The name of the branch is recorded as `submodule.<name>.branch` in |
| 305 | `.gitmodules` for `update --remote`. A special value of `.` is used to |
| 306 | indicate that the name of the branch in the submodule should be the |
| 307 | same name as the current branch in the current repository. If the |
| 308 | option is not specified, it defaults to the remote `HEAD`. |
| 309 | |
| 310 | `-f`:: |
| 311 | `--force`:: |
| 312 | Force the command to proceed, even if it would otherwise fail. |
| 313 | This option is only valid for `add`, `deinit` and `update` commands. |
| 314 | `add`;; allow adding an otherwise ignored submodule path. |
| 315 | This option is also used to bypass a check that the submodule's name |
| 316 | is not already in use. By default, `git submodule add` will fail if |
| 317 | the proposed name (which is derived from the path) is already registered |
| 318 | for another submodule in the repository. Using `--force` allows the command |
| 319 | to proceed by automatically generating a unique name by appending a number |
| 320 | to the conflicting name (e.g., if a submodule named 'child' exists, it will |
| 321 | try 'child1', and so on). |
| 322 | `deinit`;; the submodule working trees will be removed even |
| 323 | if they contain local changes. |
| 324 | `update`;; (only effective with the checkout procedure), |
| 325 | throw away local changes in submodules when switching to a |
| 326 | different commit; and always run a checkout operation in the |
| 327 | submodule, even if the commit listed in the index of the |
| 328 | containing repository matches the commit checked out in the |
| 329 | submodule. |
| 330 | |
| 331 | `--cached`:: |
| 332 | Use the index to determine the commit instead of the `HEAD`. |
| 333 | This option is only valid for `status` and `summary` commands. |
| 334 | |
| 335 | `--files`:: |
| 336 | Make the `summary` command compare the commit in the index with that in |
| 337 | the submodule `HEAD`. |
| 338 | |
| 339 | `-n<n>`:: |
| 340 | `--summary-limit=<n>`:: |
| 341 | Limit the `summary` size (number of commits shown in total) to _<n>_. |
| 342 | Giving 0 will disable the summary; a negative number means unlimited |
| 343 | (the default). This limit only applies to modified submodules. The |
| 344 | size is always limited to 1 for added/deleted/typechanged submodules. |
| 345 | |
| 346 | `--remote`:: |
| 347 | Instead of using the superproject's recorded SHA-1 to update the |
| 348 | submodule, use the status of the submodule's remote-tracking branch. |
| 349 | This option is only valid for the `update` command. The remote used |
| 350 | is branch's remote (`branch.<name>.remote`), defaulting to `origin`. |
| 351 | The remote branch used defaults to the remote `HEAD`, but the branch |
| 352 | name may be overridden by setting the `submodule.<name>.branch` |
| 353 | option in either `.gitmodules` or `.git/config` (with `.git/config` |
| 354 | taking precedence). |
| 355 | + |
| 356 | This works for any of the supported update procedures (`--checkout`, |
| 357 | `--rebase`, etc.). The only change is the source of the target SHA-1. |
| 358 | For example, `submodule update --remote --merge` will merge upstream |
| 359 | submodule changes into the submodules, while `submodule update |
| 360 | --merge` will merge superproject gitlink changes into the submodules. |
| 361 | + |
| 362 | In order to ensure a current tracking branch state, `update --remote` |
| 363 | fetches the submodule's remote repository before calculating the |
| 364 | SHA-1. If you don't want to fetch, you should use `submodule update |
| 365 | --remote --no-fetch`. |
| 366 | + |
| 367 | Use this option to integrate changes from the upstream subproject with |
| 368 | your submodule's current `HEAD`. Alternatively, you can run `git pull` |
| 369 | from the submodule, which is equivalent except for the remote branch |
| 370 | name: `update --remote` uses the default upstream repository and |
| 371 | `submodule.<name>.branch`, while `git pull` uses the submodule's |
| 372 | `branch.<name>.merge`. Prefer `submodule.<name>.branch` if you want |
| 373 | to distribute the default upstream branch with the superproject and |
| 374 | `branch.<name>.merge` if you want a more native feel while working in |
| 375 | the submodule itself. |
| 376 | |
| 377 | `-N`:: |
| 378 | `--no-fetch`:: |
| 379 | Don't fetch new objects from the remote site. |
| 380 | This option is only valid for the `update` command. |
| 381 | |
| 382 | `--checkout`:: |
| 383 | Checkout the commit recorded in the superproject on a detached `HEAD` |
| 384 | in the submodule. This option is only valid for the `update` command. |
| 385 | This is the default behavior, the main use of |
| 386 | this option is to override `submodule.<name>.update` when set to |
| 387 | a value other than `checkout`. |
| 388 | If the key `submodule.<name>.update` is either not explicitly set or |
| 389 | set to `checkout`, this option is implicit. |
| 390 | |
| 391 | `--merge`:: |
| 392 | Merge the commit recorded in the superproject into the current branch |
| 393 | of the submodule. This option is only valid for the `update` command. |
| 394 | If this option is given, the submodule's `HEAD` will |
| 395 | not be detached. If a merge failure prevents this process, you will |
| 396 | have to resolve the resulting conflicts within the submodule with the |
| 397 | usual conflict resolution tools. |
| 398 | If the key `submodule.<name>.update` is set to `merge`, this option is |
| 399 | implicit. |
| 400 | |
| 401 | `--rebase`:: |
| 402 | Rebase the current branch onto the commit recorded in the superproject. |
| 403 | This option is only valid for the `update` command. The submodule's `HEAD` will not |
| 404 | be detached. If a merge failure prevents this process, you will have |
| 405 | to resolve these failures with linkgit:git-rebase[1]. |
| 406 | If the key `submodule.<name>.update` is set to `rebase`, this option is |
| 407 | implicit. |
| 408 | |
| 409 | `--init`:: |
| 410 | Initialize all submodules for which `git submodule init` has not been |
| 411 | called so far before updating. This option is only valid for the `update` |
| 412 | command. |
| 413 | |
| 414 | |
| 415 | `--name=<name>`:: |
| 416 | Set the submodule's name to the given string instead of defaulting to its path. _<name>_ |
| 417 | must be valid as a directory name and may not end with a `/`. |
| 418 | |
| 419 | `--reference=<repository>`:: |
| 420 | Pass the local _<repository>_ as a reference when cloning the submodule. |
| 421 | This option is only valid for `add` and `update` commands. |
| 422 | These commands sometimes need to clone a remote repository. In this case, |
| 423 | this option will be passed to the linkgit:git-clone[1] command. |
| 424 | + |
| 425 | NOTE: Do *not* use this option unless you have read the note |
| 426 | for linkgit:git-clone[1]'s `--reference`, `--shared`, and `--dissociate` |
| 427 | options carefully. |
| 428 | |
| 429 | `--dissociate`:: |
| 430 | After using a reference repository to clone from, do not rely on it anymore. |
| 431 | This option is only valid for `add` and `update` commands. |
| 432 | These commands sometimes need to clone a remote repository. In this case, |
| 433 | this option will be passed to the linkgit:git-clone[1] command. |
| 434 | + |
| 435 | NOTE: See the NOTE above for the `--reference` option. |
| 436 | |
| 437 | `--recursive`:: |
| 438 | Traverse submodules recursively. This option is only valid for `foreach`, |
| 439 | `update`, `status` and `sync` commands. The operation is performed not |
| 440 | only in the submodules of the current repo, but also |
| 441 | in any nested submodules inside those submodules (and so on). |
| 442 | |
| 443 | `--depth=<depth>`:: |
| 444 | Create a 'shallow' clone with a history truncated to the _<depth>_ revisions. |
| 445 | This option is valid for `add` and `update` commands. See linkgit:git-clone[1] |
| 446 | |
| 447 | `--recommend-shallow`:: |
| 448 | `--no-recommend-shallow`:: |
| 449 | Recommend or not shallow cloning of submodules. |
| 450 | This option is only valid for the `update` command. |
| 451 | The initial clone of a submodule will use the recommended |
| 452 | `submodule.<name>.shallow` as provided by the `.gitmodules` file |
| 453 | by default. To ignore the suggestions use `--no-recommend-shallow`. |
| 454 | |
| 455 | `-j<n>`:: |
| 456 | `--jobs=<n>`:: |
| 457 | Clone new submodules in parallel with _<n>_ jobs. |
| 458 | This option is only valid for the `update` command. |
| 459 | Defaults to the `submodule.fetchJobs` option. |
| 460 | |
| 461 | `--single-branch`:: |
| 462 | `--no-single-branch`:: |
| 463 | Clone only one branch during update: `HEAD` or one specified by `--branch`. |
| 464 | This option is only valid for the `update` command. |
| 465 | |
| 466 | `<path>...`:: |
| 467 | Paths to submodule(s). When specified this will restrict the command |
| 468 | to only operate on the submodules found at the specified paths. |
| 469 | (This argument is required with `add`). |
| 470 | |
| 471 | FILES |
| 472 | ----- |
| 473 | When initializing submodules, a `.gitmodules` file in the top-level directory |
| 474 | of the containing repository is used to find the URL of each submodule. |
| 475 | This file should be formatted in the same way as `$GIT_DIR/config`. The key |
| 476 | to each submodule URL is `submodule.<name>.url`. See linkgit:gitmodules[5] |
| 477 | for details. |
| 478 | |
| 479 | SEE ALSO |
| 480 | -------- |
| 481 | linkgit:gitsubmodules[7], linkgit:gitmodules[5]. |
| 482 | |
| 483 | GIT |
| 484 | --- |
| 485 | Part of the linkgit:git[1] suite |