Merge branch 'jl/nor-or-nand-and'
[gitweb.git] / Documentation / git-submodule.txt
index c99d795618f59bf98969b551f2a931680534f18e..89c4d3e39474ed601255371c30b98bdd569f671d 100644 (file)
@@ -10,12 +10,13 @@ SYNOPSIS
 --------
 [verse]
 'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>]
-             [--reference <repository>] [--] <repository> [<path>]
+             [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]
 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
 'git submodule' [--quiet] init [--] [<path>...]
+'git submodule' [--quiet] deinit [-f|--force] [--] <path>...
 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
-             [-f|--force] [--rebase] [--reference <repository>]
-             [--merge] [--recursive] [--] [<path>...]
+             [-f|--force] [--rebase|--merge] [--reference <repository>]
+             [--depth <depth>] [--recursive] [--] [<path>...]
 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
              [commit] [--] [<path>...]
 'git submodule' [--quiet] foreach [--recursive] <command>
@@ -76,6 +77,8 @@ argument <path> is the relative location for the cloned submodule
 to exist in the superproject. If <path> is not given, the
 "humanish" part of the source repository is used ("repo" for
 "/path/to/repo.git" and "foo" for "host.xz:foo/.git").
+The <path> is also used as the submodule's logical name in its
+configuration entries unless `--name` is used to specify a logical name.
 +
 <repository> is the URL of the new submodule's origin repository.
 This may be either an absolute URL, or (if it begins with ./
@@ -123,8 +126,10 @@ 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::
-       Initialize the submodules, i.e. register each submodule name
-       and url found in .gitmodules into .git/config.
+       Initialize the submodules recorded in the index (which were
+       added and committed elsewhere) by copying submodule
+       names and urls from .gitmodules to .git/config.
+       Optional <path> arguments limit which submodules will be initialized.
        It will also copy the value of `submodule.$name.update` into
        .git/config.
        The key used in .git/config is `submodule.$name.url`.
@@ -135,13 +140,28 @@ init::
        the explicit 'init' step if you do not intend to customize
        any submodule locations.
 
+deinit::
+       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 work tree anymore. If
+       you really want to remove a submodule from the repository and commit
+       that use linkgit:git-rm[1] instead.
++
+If `--force` is specified, the submodule's work tree will be removed even if
+it contains local modifications.
+
 update::
        Update the registered submodules, i.e. clone missing submodules and
        checkout the commit specified in the index of the containing repository.
        This will make the submodules HEAD be detached unless `--rebase` or
        `--merge` is specified or the key `submodule.$name.update` is set to
        `rebase`, `merge` or `none`. `none` can be overridden by specifying
-       `--checkout`.
+       `--checkout`. Setting the key `submodule.$name.update` to `!command`
+       will cause `command` to be run. `command` can be any arbitrary shell
+       command that takes a single argument, namely the sha1 to update to.
 +
 If the submodule is not yet initialized, and you just want to use the
 setting as stored in .gitmodules, you can automatically initialize the
@@ -209,13 +229,15 @@ OPTIONS
 -b::
 --branch::
        Branch of repository to add as submodule.
-       The name of the branch is recorded as `submodule.<path>.branch` in
+       The name of the branch is recorded as `submodule.<name>.branch` in
        `.gitmodules` for `update --remote`.
 
 -f::
 --force::
-       This option is only valid for add and update commands.
+       This option is only valid for add, deinit and update commands.
        When running add, allow adding an otherwise ignored submodule path.
+       When running deinit the submodule work trees will be removed even if
+       they contain local changes.
        When running update, throw away local changes in submodules when
        switching to a different commit; and always run a checkout operation
        in the submodule, even if the commit listed in the index of the
@@ -242,7 +264,7 @@ OPTIONS
 --remote::
        This option is only valid for the update command.  Instead of using
        the superproject's recorded SHA-1 to update the submodule, use the
-       status of the submodule's remote tracking branch.  The remote used
+       status of the submodule's remote-tracking branch.  The remote used
        is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
        The remote branch used defaults to `master`, but the branch name may
        be overridden by setting the `submodule.<name>.branch` option in
@@ -259,12 +281,31 @@ In order to ensure a current tracking branch state, `update --remote`
 fetches the submodule's remote repository before calculating the
 SHA-1.  If you don't want to fetch, you should use `submodule update
 --remote --no-fetch`.
++
+Use this option to integrate changes from the upstream subproject with
+your submodule's current HEAD.  Alternatively, you can run `git pull`
+from the submodule, which is equivalent except for the remote branch
+name: `update --remote` uses the default upstream repository and
+`submodule.<name>.branch`, while `git pull` uses the submodule's
+`branch.<name>.merge`.  Prefer `submodule.<name>.branch` if you want
+to distribute the default upstream branch with the superproject and
+`branch.<name>.merge` if you want a more native feel while working in
+the submodule itself.
 
 -N::
 --no-fetch::
        This option is only valid for the update command.
        Don't fetch new objects from the remote site.
 
+--checkout::
+       This option is only valid for the update command.
+       Checkout the commit recorded in the superproject on a detached HEAD
+       in the submodule. This is the default behavior, the main use of
+       this option is to override `submodule.$name.update` when set to
+       `merge`, `rebase` or `none`.
+       If the key `submodule.$name.update` is either not explicitly set or
+       set to `checkout`, this option is implicit.
+
 --merge::
        This option is only valid for the update command.
        Merge the commit recorded in the superproject into the current branch
@@ -308,6 +349,12 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully.
        only in the submodules of the current repo, but also
        in any nested submodules inside those submodules (and so on).
 
+--depth::
+       This option is valid for add and update commands. Create a 'shallow'
+       clone with a history truncated to the specified number of revisions.
+       See linkgit:git-clone[1]
+
+
 <path>...::
        Paths to submodule(s). When specified this will restrict the command
        to only operate on the submodules found at the specified paths.