| 1 | gitsubmodules(7) |
| 2 | ================ |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | gitsubmodules - Mounting one repository inside another |
| 7 | |
| 8 | SYNOPSIS |
| 9 | -------- |
| 10 | .gitmodules, $GIT_DIR/config |
| 11 | |
| 12 | ------------------ |
| 13 | git submodule |
| 14 | git <command> --recurse-submodules |
| 15 | ------------------ |
| 16 | |
| 17 | DESCRIPTION |
| 18 | ----------- |
| 19 | |
| 20 | A submodule is a repository embedded inside another repository. |
| 21 | The submodule has its own history; the repository it is embedded |
| 22 | in is called a superproject. |
| 23 | |
| 24 | On the filesystem, a submodule usually (but not always - see FORMS below) |
| 25 | consists of (i) a Git directory located under the `$GIT_DIR/modules/` |
| 26 | directory of its superproject, (ii) a working directory inside the |
| 27 | superproject's working directory, and a `.git` file at the root of |
| 28 | the submodule's working directory pointing to (i). |
| 29 | |
| 30 | Assuming the submodule has a Git directory at `$GIT_DIR/modules/foo/` |
| 31 | and a working directory at `path/to/bar/`, the superproject tracks the |
| 32 | submodule via a `gitlink` entry in the tree at `path/to/bar` and an entry |
| 33 | in its `.gitmodules` file (see linkgit:gitmodules[5]) of the form |
| 34 | `submodule.foo.path = path/to/bar`. |
| 35 | |
| 36 | The `gitlink` entry contains the object name of the commit that the |
| 37 | superproject expects the submodule's working directory to be at. |
| 38 | |
| 39 | The section `submodule.foo.*` in the `.gitmodules` file gives additional |
| 40 | hints to Git's porcelain layer. For example, the `submodule.foo.url` |
| 41 | setting specifies where to obtain the submodule. |
| 42 | |
| 43 | Submodules can be used for at least two different use cases: |
| 44 | |
| 45 | 1. Using another project while maintaining independent history. |
| 46 | Submodules allow you to contain the working tree of another project |
| 47 | within your own working tree while keeping the history of both |
| 48 | projects separate. Also, since submodules are fixed to an arbitrary |
| 49 | version, the other project can be independently developed without |
| 50 | affecting the superproject, allowing the superproject project to |
| 51 | fix itself to new versions only when desired. |
| 52 | |
| 53 | 2. Splitting a (logically single) project into multiple |
| 54 | repositories and tying them back together. This can be used to |
| 55 | overcome current limitations of Git's implementation to have |
| 56 | finer grained access: |
| 57 | |
| 58 | * Size of the Git repository: |
| 59 | In its current form Git scales up poorly for large repositories containing |
| 60 | content that is not compressed by delta computation between trees. |
| 61 | For example, you can use submodules to hold large binary assets |
| 62 | and these repositories can be shallowly cloned such that you do not |
| 63 | have a large history locally. |
| 64 | * Transfer size: |
| 65 | In its current form Git requires the whole working tree present. It |
| 66 | does not allow partial trees to be transferred in fetch or clone. |
| 67 | If the project you work on consists of multiple repositories tied |
| 68 | together as submodules in a superproject, you can avoid fetching the |
| 69 | working trees of the repositories you are not interested in. |
| 70 | * Access control: |
| 71 | By restricting user access to submodules, this can be used to implement |
| 72 | read/write policies for different users. |
| 73 | |
| 74 | The configuration of submodules |
| 75 | ------------------------------- |
| 76 | |
| 77 | Submodule operations can be configured using the following mechanisms |
| 78 | (from highest to lowest precedence): |
| 79 | |
| 80 | * The command line for those commands that support taking submodules |
| 81 | as part of their pathspecs. Most commands have a boolean flag |
| 82 | `--recurse-submodules` which specifies whether to recurse into submodules. |
| 83 | Examples are `grep` and `checkout`. |
| 84 | Some commands take enums, such as `fetch` and `push`, where you can |
| 85 | specify how submodules are affected. |
| 86 | |
| 87 | * The configuration inside the submodule. This includes `$GIT_DIR/config` |
| 88 | in the submodule, but also settings in the tree such as a `.gitattributes` |
| 89 | or `.gitignore` files that specify behavior of commands inside the |
| 90 | submodule. |
| 91 | + |
| 92 | For example an effect from the submodule's `.gitignore` file |
| 93 | would be observed when you run `git status --ignore-submodules=none` in |
| 94 | the superproject. This collects information from the submodule's working |
| 95 | directory by running `status` in the submodule while paying attention |
| 96 | to the `.gitignore` file of the submodule. |
| 97 | + |
| 98 | The submodule's `$GIT_DIR/config` file would come into play when running |
| 99 | `git push --recurse-submodules=check` in the superproject, as this would |
| 100 | check if the submodule has any changes not published to any remote. The |
| 101 | remotes are configured in the submodule as usual in the `$GIT_DIR/config` |
| 102 | file. |
| 103 | |
| 104 | * The configuration file `$GIT_DIR/config` in the superproject. |
| 105 | Git only recurses into active submodules (see "ACTIVE SUBMODULES" |
| 106 | section below). |
| 107 | + |
| 108 | If the submodule is not yet initialized, then the configuration |
| 109 | inside the submodule does not exist yet, so where to |
| 110 | obtain the submodule from is configured here for example. |
| 111 | |
| 112 | * The `.gitmodules` file inside the superproject. A project usually |
| 113 | uses this file to suggest defaults for the upstream collection |
| 114 | of repositories for the mapping that is required between a |
| 115 | submodule's name and its path. |
| 116 | + |
| 117 | This file mainly serves as the mapping between the name and path of submodules |
| 118 | in the superproject, such that the submodule's Git directory can be |
| 119 | located. |
| 120 | + |
| 121 | If the submodule has never been initialized, this is the only place |
| 122 | where submodule configuration is found. It serves as the last fallback |
| 123 | to specify where to obtain the submodule from. |
| 124 | |
| 125 | FORMS |
| 126 | ----- |
| 127 | |
| 128 | Submodules can take the following forms: |
| 129 | |
| 130 | * The basic form described in DESCRIPTION with a Git directory, |
| 131 | a working directory, a `gitlink`, and a `.gitmodules` entry. |
| 132 | |
| 133 | * "Old-form" submodule: A working directory with an embedded |
| 134 | `.git` directory, and the tracking `gitlink` and `.gitmodules` entry in |
| 135 | the superproject. This is typically found in repositories generated |
| 136 | using older versions of Git. |
| 137 | + |
| 138 | It is possible to construct these old form repositories manually. |
| 139 | + |
| 140 | When deinitialized or deleted (see below), the submodule's Git |
| 141 | directory is automatically moved to `$GIT_DIR/modules/<name>/` |
| 142 | of the superproject. |
| 143 | |
| 144 | * Deinitialized submodule: A `gitlink`, and a `.gitmodules` entry, |
| 145 | but no submodule working directory. The submodule's Git directory |
| 146 | may be there as after deinitializing the Git directory is kept around. |
| 147 | The directory which is supposed to be the working directory is empty instead. |
| 148 | + |
| 149 | A submodule can be deinitialized by running `git submodule deinit`. |
| 150 | Besides emptying the working directory, this command only modifies |
| 151 | the superproject's `$GIT_DIR/config` file, so the superproject's history |
| 152 | is not affected. This can be undone using `git submodule init`. |
| 153 | |
| 154 | * Deleted submodule: A submodule can be deleted by running |
| 155 | `git rm <submodule-path> && git commit`. This can be undone |
| 156 | using `git revert`. |
| 157 | + |
| 158 | The deletion removes the superproject's tracking data, which are |
| 159 | both the `gitlink` entry and the section in the `.gitmodules` file. |
| 160 | The submodule's working directory is removed from the file |
| 161 | system, but the Git directory is kept around as it to make it |
| 162 | possible to checkout past commits without requiring fetching |
| 163 | from another repository. |
| 164 | + |
| 165 | To completely remove a submodule, manually delete |
| 166 | `$GIT_DIR/modules/<name>/`. |
| 167 | |
| 168 | ACTIVE SUBMODULES |
| 169 | ----------------- |
| 170 | |
| 171 | A submodule is considered active, |
| 172 | |
| 173 | 1. if `submodule.<name>.active` is set to `true` |
| 174 | + |
| 175 | or |
| 176 | |
| 177 | 2. if the submodule's path matches the pathspec in `submodule.active` |
| 178 | + |
| 179 | or |
| 180 | |
| 181 | 3. if `submodule.<name>.url` is set. |
| 182 | |
| 183 | and these are evaluated in this order. |
| 184 | |
| 185 | For example: |
| 186 | |
| 187 | [submodule "foo"] |
| 188 | active = false |
| 189 | url = https://example.org/foo |
| 190 | [submodule "bar"] |
| 191 | active = true |
| 192 | url = https://example.org/bar |
| 193 | [submodule "baz"] |
| 194 | url = https://example.org/baz |
| 195 | |
| 196 | In the above config only the submodules 'bar' and 'baz' are active, |
| 197 | 'bar' due to (1) and 'baz' due to (3). 'foo' is inactive because |
| 198 | (1) takes precedence over (3) |
| 199 | |
| 200 | Note that (3) is a historical artefact and will be ignored if the |
| 201 | (1) and (2) specify that the submodule is not active. In other words, |
| 202 | if we have a `submodule.<name>.active` set to `false` or if the |
| 203 | submodule's path is excluded in the pathspec in `submodule.active`, the |
| 204 | url doesn't matter whether it is present or not. This is illustrated in |
| 205 | the example that follows. |
| 206 | |
| 207 | [submodule "foo"] |
| 208 | active = true |
| 209 | url = https://example.org/foo |
| 210 | [submodule "bar"] |
| 211 | url = https://example.org/bar |
| 212 | [submodule "baz"] |
| 213 | url = https://example.org/baz |
| 214 | [submodule "bob"] |
| 215 | ignore = true |
| 216 | [submodule] |
| 217 | active = b* |
| 218 | active = :(exclude) baz |
| 219 | |
| 220 | In here all submodules except 'baz' (foo, bar, bob) are active. |
| 221 | 'foo' due to its own active flag and all the others due to the |
| 222 | submodule active pathspec, which specifies that any submodule |
| 223 | starting with 'b' except 'baz' are also active, regardless of the |
| 224 | presence of the .url field. |
| 225 | |
| 226 | Workflow for a third party library |
| 227 | ---------------------------------- |
| 228 | |
| 229 | # Add a submodule |
| 230 | git submodule add <URL> <path> |
| 231 | |
| 232 | # Occasionally update the submodule to a new version: |
| 233 | git -C <path> checkout <new-version> |
| 234 | git add <path> |
| 235 | git commit -m "update submodule to new version" |
| 236 | |
| 237 | # See the list of submodules in a superproject |
| 238 | git submodule status |
| 239 | |
| 240 | # See FORMS on removing submodules |
| 241 | |
| 242 | |
| 243 | Workflow for an artificially split repo |
| 244 | --------------------------------------- |
| 245 | |
| 246 | # Enable recursion for relevant commands, such that |
| 247 | # regular commands recurse into submodules by default |
| 248 | git config --global submodule.recurse true |
| 249 | |
| 250 | # Unlike most other commands below, clone still needs |
| 251 | # its own recurse flag: |
| 252 | git clone --recurse <URL> <directory> |
| 253 | cd <directory> |
| 254 | |
| 255 | # Get to know the code: |
| 256 | git grep foo |
| 257 | git ls-files --recurse-submodules |
| 258 | |
| 259 | [NOTE] |
| 260 | `git ls-files` also requires its own `--recurse-submodules` flag. |
| 261 | |
| 262 | # Get new code |
| 263 | git fetch |
| 264 | git pull --rebase |
| 265 | |
| 266 | # Change worktree |
| 267 | git checkout |
| 268 | git reset |
| 269 | |
| 270 | Implementation details |
| 271 | ---------------------- |
| 272 | |
| 273 | When cloning or pulling a repository containing submodules the submodules |
| 274 | will not be checked out by default; you can instruct `clone` to recurse |
| 275 | into submodules. The `init` and `update` subcommands of `git submodule` |
| 276 | will maintain submodules checked out and at an appropriate revision in |
| 277 | your working tree. Alternatively you can set `submodule.recurse` to have |
| 278 | `checkout` recurse into submodules (note that `submodule.recurse` also |
| 279 | affects other Git commands, see linkgit:git-config[1] for a complete list). |
| 280 | |
| 281 | |
| 282 | SEE ALSO |
| 283 | -------- |
| 284 | linkgit:git-submodule[1], linkgit:gitmodules[5]. |
| 285 | |
| 286 | GIT |
| 287 | --- |
| 288 | Part of the linkgit:git[1] suite |