home | helfen
GIT-SUBMODULE(1) Git Manual GIT-SUBMODULE(1)NAME git-submodule - Initialize, update or inspect submodulesSYNOPSIS git submodule git submodule add <repository> git submodule status git submodule init git submodule deinit (--all| <path>...) git submodule update git submodule set-branch <path> git submodule set-url <path> <newurl> git submodule summary git submodule foreach <command> git submodule sync git submodule absorbgitdirs DESCRIPTION Inspects, updates and manages submodules. For moreinformation about submodules, see gitsubmodules(7).COMMANDS With no arguments, showsthe status of existing submodules. Several subcommands are available to perform operations on the submodules. add <repository> Add the given repository as a submodule at the givenpath tothe changeset tobe committed next to the current project: the current project is termed the "superproject". <repository>is the URL of the new submodule's origin repository. Thismay be either an absolute URL, or (if it beginswith ./or ../), the location relative to the superproject's default remote repository (Please note thatto specify a repositoryfoo.gitwhich is located right next to a superproject bar.git, you'll haveto use ../foo.git instead of ./foo.git - asone might expect when following the rules for relative URLs - because the evaluation of relative URLs in Gitis identical tothat ofrelative directories). The default remote is the remote of the remote-tracking branch of the current branch. If no such remote-tracking branch existsor the HEADis detached, "origin" is assumed to be the default remote. If the superproject doesn't have a default remote configured the superprojectis its own authoritative upstream and the current working directory isused instead. The optionalargument <path>is the relativelocation for the cloned submodule to exist inthe superproject. If <path> is not given, the canonicalpart ofthe source repository is used ("repo" for "/path/to/repo.git" and "foo" for "host.xz:foo/.git"). If <path> exists and isalreadya validGit repository,then itis staged for commit without cloning. The <path> is also used as the submodule's logical name in its configuration entries unless--name is used to specify alogicalname. The given URL is recorded into .gitmodules for use by subsequent users cloning the superproject. If the URL is given relativeto the superproject's repository, the presumption is the superproject and submodule repositories will be kept togetherin the same relative location, and only the superproject's URL needs to be provided. git-submodule will correctlylocate the submodule using the relative URLin .gitmodules. status Showthe status of the submodules. This willprint the SHA-1of the currently checked out commitfor each submodule, along with the submodule path and the output of gitdescribe for the SHA-1.Each SHA-1 will possibly be prefixed with- if the submodule is not initialized,+ if the currently checked out submodule commitdoes not match the SHA-1 found inthe index of the containing repository and U if thesubmodule has merge conflicts. If --cached is specified, this command will instead print the SHA-1 recorded in the superprojectfor each submodule. If --recursive is specified,this command will recurse into nested submodules, and showtheir status aswell. If you are only interested in changes of thecurrently initialized submodules with respect to the commit recorded in the index or the HEAD, git-status(1) and git-diff(1) will provide that information too (and canalso report changes to a submodule's work tree). init Initialize the submodules recorded in the index (which were added and committed elsewhere) by setting submodule.$name.url in .git/config.It usesthe same setting from .gitmodules as a template. Ifthe URLis relative, itwill beresolved using the default remote. If there is no default remote, the current repository will be assumed to be upstream. Optional <path> arguments limit which submodules will be initialized.If no path is specifiedand submodule.active has been configured, submodules configured tobe active will be initialized, otherwise all submodules areinitialized. Whenpresent, it will also copy the value of submodule.$name.update. Thiscommanddoes not alter existing information in .git/config. You can then customize the submodule clone URLs in .git/config for your local setup and proceed to git submodule update; you can also just use git submodule update--init without the explicitinit step if you do notintend to customize any submodule locations. See the add subcommand for the definition ofdefaultremote. deinit (--all| <path>...) Unregister the givensubmodules, i.e. removethe whole submodule.$name section from.git/config together with theirwork tree. Further calls to git submoduleupdate,git submodule foreach and git submodule sync will skip anyunregistered submodulesuntil theyare initializedagain, so use this command if you don'twant to have a local checkout of the submodule inyour working tree anymore. Whenthe command is run without pathspec, iterrors out, instead of deinit-ing everything, to prevent mistakes. If --force is specified, thesubmodule's working tree will be removed evenif it contains local modifications. If you really want to removea submodule from the repositoryand commit that use git-rm(1) instead. See gitsubmodules(7) for removal options. update recommend-shallow] single-branch] 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. The update procedures supported both fromthe command lineas wellas through the submodule.<name>.update configuration are: checkout the commit recorded in the superproject will be checked out in the submodule ona detached HEAD. If --force is specified,the submodule will be checked out (using git checkout --force), even if the commitspecified in the index of thecontaining repository already matches the commit checked out in the submodule. rebase the current branch of the submodule willbe rebased ontothe commit recorded in the superproject. merge the commit recorded in the superproject will be merged into the current branch in the submodule. The following updateprocedures are only available via the submodule.<name>.update configuration variable: custom command arbitrary shell command that takes a single argument (the sha1 of the commit recorded in the superproject) is executed.When submodule.<name>.update is set to !command, the remainder after the exclamation mark is the custom command. none the submodule isnot updated. If the submodule is not yet initialized, andyou 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 nestedsubmodules within. set-branch (-b|--branch)<branch> <path>, set-branch (-d|--default) <path> Setsthe default remote tracking branch for the submodule. The --branch option allows the remote branch to be specified. The --default option removes thesubmodule.<name>.branchconfiguration key,which causes the tracking branch to default to the remote HEAD. set-url <path> <newurl> Setsthe URLof the specified submodule to <newurl>.Then, it will automatically synchronize the submodule's new remoteURL configuration. summary Showcommit summary between the given commit(defaults to HEAD) and working tree/index. For a submodule in question, a series of commits in the submodule between thegiven super project commit and the index orworkingtree (switched by --cached) areshown. If the option --files is given, show the series of commits in the submodule between the index of the super project andthe working treeof the submodule (this option doesn't allow to use the --cached option or to provide an explicit commit). Using the --submodule=log option with git-diff(1) will provide that information too. foreach <command> Evaluates anarbitrary shellcommandin eachcheckedout submodule. The command has access to the variables $name, $sm_path, $displaypath, $sha1 and $toplevel: $name is the nameof the relevant submodule section in .gitmodules, $sm_path is the path of the submodule as recorded inthe immediate superproject, $displaypathcontains the relative path fromthe current working directory tothe submodules root directory, $sha1 isthe commit as recorded in the immediate superproject, and $toplevel is the absolute path to thetop-level of the immediate superproject. Note thatto avoid conflicts with$PATH on Windows, the $path variable is now a deprecated synonym of $sm_path variable. Any submodules defined in the superproject but not checked out are ignored by this command. Unless given --quiet, foreach prints the name of each submodule before evaluating the command. If --recursive is given, submodules are traversed recursively(i.e. the givenshell command is evaluatedin nested submodules aswell). A non-zero return from the command in any submodulecauses the processing to terminate. Thiscan be overridden by adding || : to theend of the command. As an example, the command below will show the path and currently checked out commit for each submodule: git submodule foreach 'echo $sm_path `git rev-parse HEAD`' sync Synchronizessubmodules' remote URL configuration setting tothe value specified in .gitmodules. It will onlyaffect those submodules which already have a URL entry in.git/config (that is the case when they are initialized or freshly added). This is useful when submodule URLs change upstream and you need to update yourlocal repositories accordingly. git submodule sync synchronizes all submodules whilegit submodule sync-- A synchronizes submodule "A"only. If --recursive is specified,this command will recurse into the registered submodules, and sync any nested submodules within. absorbgitdirs If agit directory of a submodule isinside the submodule, move the git directory of thesubmodule into its superproject's $GIT_DIR/modules path and then connect the git directory andits working directory bysettingthe core.worktree and adding a .git filepointing to thegit directory embedded in the superprojects git directory. A repositorythat was clonedindependently and lateradded as a submodule orold setups havethe submodules git directory inside the submodule instead of embedded into the superprojects git directory. Thiscommandis recursive bydefault.OPTIONS -q, --quiet Onlyprint error messages. --progress Thisoption is only valid for add and updatecommands. Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -qis specified. This flagforces progress status evenif the standarderror stream isnot directed to aterminal. --all Thisoption is only valid for the deinit command. Unregisterall submodules in the working tree. -b <branch>, --branch <branch> Branch of repositoryto add as submodule. The name of the branch is recorded as submodule.<name>.branch in .gitmodules for update --remote. A special value of. is used to indicate that thename of the branch in thesubmodule should be thesame name as the current branch in the current repository. Ifthe option is not specified, it defaults to the remoteHEAD. -f, --force Thisoption is only valid for add, deinit and updatecommands. When running add,allow adding anotherwise ignored submodule path. When running deinit the submoduleworkingtrees will be removed even if theycontainlocal changes. When running update (only effective withthe checkout procedure), throw away local changes in submodules when switching toa different commit; andalways run a checkout operation in the submodule,even ifthe commit listed in the index ofthe containing repository matches the commit checked out in the submodule. --cached Thisoption is only valid for statusand summary commands. These commands typically use the commit found in the submodule HEAD, but withthis option, the commitstored in the index is used instead. --files Thisoption is only valid for the summary command. This command compares thecommit in the index with that in the submodule HEAD whenthis option is used. -n, --summary-limit Thisoption is only valid for the summary command. Limit the summary size(numberof commits shown in total). Giving 0 will disable the summary;a negative number meansunlimited (the default). This limitonly applies tomodified submodules. The size is always limited to1 for added/deleted/typechangedsubmodules. --remote Thisoption is only valid for the update command. Instead ofusing the superproject's recorded SHA-1 toupdate the submodule, use the status of the submodule's remote-tracking branch. The remoteused is branch's remote (branch.<name>.remote), defaulting to origin. The remote branch used defaults to the remote HEAD, but the branch namemay be overridden by setting the submodule.<name>.branch option in either .gitmodulesor .git/config (with .git/config taking precedence). Thisworks for any of the supported update procedures (--checkout, --rebase, etc.). Theonly change is the source of the targetSHA-1. For example,submodule update --remote --merge will merge upstream submodule changes into the submodules, whilesubmodule update --merge willmerge superproject gitlink changes intothe submodules. In order to ensure acurrenttracking branchstate, update --remote fetches the submodule's remote repository before calculatingthe SHA-1. If you don't want to fetch, you should use submodule update --remote --no-fetch. Use this option to integratechangesfrom the upstream subproject withyour submodule's current HEAD. Alternatively, you can run git pullfrom the submodule, which is equivalentexcept for the remote branch name:update --remoteuses the default upstream repository and submodule.<name>.branch,while git pull uses thesubmodule's branch.<name>.merge.Prefer submodule.<name>.branch if you want to distribute the default upstream branch with the superprojectand branch.<name>.merge if you want a more native feel while working in the submodule itself. -N, --no-fetch Thisoption is only valid for the update command. Don't fetch new objects fromthe remote site. --checkout Thisoption 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, themain use of this option is tooverride submodule.$name.updatewhen set to a value other than checkout.If the key submodule.$name.update is either not explicitly set or set tocheckout, this option is implicit. --merge Thisoption is only valid for the update command. Merge the commit recorded in the superprojectinto the current branchof the submodule. If this option isgiven, the submodule's HEAD will not be detached.If a merge failure prevents this process, you will haveto resolve the resulting conflicts within the submodulewith the usual conflict resolution tools.If the key submodule.$name.update is set to merge, thisoption is implicit. --rebase Thisoption is only valid for the update command. Rebase the current branch onto the commit recorded in the superproject.If thisoption is given, the submodule's HEAD will not be detached. If a merge failure prevents this process, you will haveto resolve these failures with git-rebase(1). If the key submodule.$name.update is set to rebase, this optionis implicit. --init Thisoption is only valid for the update command. Initializeall submodules for which"git submodule init" has not been called so far before updating. --name Thisoption is only valid for the add command. It sets the submodule's name to the given stringinsteadof defaulting to its path. The name must be validas a directory name andmay notend witha /. --reference <repository> Thisoption is only valid for add and updatecommands. These commands sometimes need to clone a remote repository. In this case, thisoption will be passed to the git-clone(1) command. NOTE: Do notuse this optionunless you haveread the note for git- clone(1)'s --reference, --shared, and --dissociate options carefully. --dissociate Thisoption is only valid for add and updatecommands. These commands sometimes need to clone a remote repository. In this case, thisoption will be passed to the git-clone(1) command. NOTE: see the NOTE for the --reference option. --recursive Thisoption is only valid for foreach, update, status and sync commands. Traverse submodules recursively. The operation is performed not only in the submodulesof the current repo, but also in any nested submodules inside those submodules (and so on). --depth Thisoption is validfor addand update commands. Create a shallow clone with ahistorytruncated to the specified number of revisions. See git-clone(1) --recommend-shallow Thisoption is only valid for the update command. The initial clone of asubmodule will use the recommended submodule.<name>.shallow as provided by the .gitmodules file by default.To ignore the suggestions use --no-recommend-shallow. -j <n>, --jobs <n> Thisoption is only valid for the update command. Clone new submodules in parallel with as many jobs. Defaults to the submodule.fetchJobs option. --single-branch Thisoption is only valid for the update command. Clone onlyone branch during update: HEAD or one specified by --branch. <path>... Paths to submodule(s). When specified this will restrict the command to only operate on the submodules found at the specified paths. (Thisargument is required with add).FILES When initializing submodules, a .gitmodules filein the top-level directory of thecontaining repository is used to find the url of each submodule. This file should be formattedin the same wayas $GIT_DIR/config.The keyto eachsubmodule url is "submodule.$name.url". See gitmodules(5)for details.SEE ALSO gitsubmodules(7), gitmodules(5).GIT Part of the git(1) suiteGit 2.28.0 07/26/2020 GIT-SUBMODULE(1)
NAME |SYNOPSIS |DESCRIPTION |BEFEHLE |OPTIONEN |DATEIEN |SIEHE AUCH |GIT-home | Hilfe