summaryrefslogtreecommitdiff
path: root/Documentation/git-submodule.txt
AgeCommit message (Collapse)AuthorFilesLines
2017-07-12Merge branch 'sb/submodule-doc'Libravatar Junio C Hamano1-34/+10
Doc update. * sb/submodule-doc: submodules: overhaul documentation
2017-06-30Merge branch 'vs/typofixes'Libravatar Junio C Hamano1-1/+1
Many typofixes. * vs/typofixes: Spelling fixes
2017-06-27Spelling fixesLibravatar Ville Skyttä1-1/+1
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-22submodules: overhaul documentationLibravatar Stefan Beller1-34/+10
This patch aims to detangle (a) the usage of `git-submodule` from (b) the concept of submodules and (c) how the actual implementation looks like, such as where they are configured and (d) what the best practices are. To do so, move the conceptual parts of the 'git-submodule' man page to a new man page gitsubmodules(7). This new page is just like gitmodules(5), gitattributes(5), gitcredentials(7), gitnamespaces(7), gittutorial(7), which introduce a concept rather than explaining a specific command. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-22Documentation/git-submodule: cleanup "add" sectionLibravatar Kaartic Sivaraam1-28/+21
The "add" section for 'git-submodule' is redundant in its description and the short synopsis line. Fix it. Remove the redundant mentioning of the 'repository' argument being mandatory. The text is hard to read because of back-references, so remove those. Replace the word "humanish" by "canonical" as that conveys better what we do to guess the path. While at it, quote all occurrences of '.gitmodules' as that is an important file in the submodule context, also link to it on its first mention. Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-18submodule init: initialize active submodulesLibravatar Brandon Williams1-1/+3
Teach `submodule init` to initialize submodules which have been configured to be active by setting 'submodule.active' with a pathspec. Now if no path arguments are given and 'submodule.active' is configured, `init` will initialize all submodules which have been configured to be active. If no path arguments are given and 'submodule.active' is not configured, then `init` will retain the old behavior of initializing all submodules. This allows users to record more complex patterns as it saves retyping them whenever you invoke update. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28submodule init: warn about falling back to a local pathLibravatar Stefan Beller1-14/+24
When a submodule is initialized, the config variable 'submodule.<name>.url' is set depending on the value of the same variable in the .gitmodules file. When the URL indicates to be relative, then the url is computed relative to its default remote. The default remote cannot be determined accurately in all cases, such that it falls back to 'origin'. The 'origin' remote may not exist, though. In that case we give up looking for a suitable remote and we'll just assume it to be a local relative path. This can be confusing to users as there is a lot of guessing involved, which is not obvious to the user. So in the corner case of assuming a local autoritative truth, warn the user to lessen the confusion. This behavior was introduced in 4d6893200 (submodule add: allow relative repository path even when no url is set, 2011-06-06), which shared the code with submodule-init and then ported to C in 3604242f080a (submodule: port init from shell to C, 2016-04-15). In case of submodule-add, this behavior makes sense in some use cases[1], however for submodule-init there does not seem to be an immediate obvious use case to fall back to a local submodule. However there might be, so warn instead of die here. While adding the warning, also clarify the behavior of relative URLs in the documentation. [1] e.g. http://stackoverflow.com/questions/8721984/git-ignore-files-for-public-repository-but-not-for-private "store a secret locally in a submodule, with no intention to publish it" Reported-by: Shawn Pearce <spearce@spearce.org> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-15Merge branch 'jk/doc-submodule-markup-fix'Libravatar Junio C Hamano1-3/+6
Doc markup fix. * jk/doc-submodule-markup-fix: docs/git-submodule: fix unbalanced quote
2017-02-13docs/git-submodule: fix unbalanced quoteLibravatar Jeff King1-3/+6
The documentation gives an example of the submodule foreach command that uses both backticks and single-quotes. We stick the whole thing inside "+" markers to make it monospace, but the inside punctuation still needs escaping. We handle the backticks with "{backtick}", and use backslash-escaping for the single-quotes. But we missed the escaping on the second quote. Fortunately, asciidoc renders this unbalanced quote as we want (showing the quote), but asciidoctor does not. We could fix it by adding the missing backslash. However, let's take a step back. Even when rendered correctly, it's hard to read a long command stuck into the middle of a paragraph, and the important punctuation is hard to notice. Let's instead bump it into its own single-line code block. That makes both the source and the rendered result more readable, and as a bonus we don't have to worry about quoting at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-12submodule update documentation: don't repeat ourselvesLibravatar Stefan Beller1-16/+14
The documentation for the `git submodule update` command, repeats itself for each update option, "This is done when <option> is given, or no option is given and `submodule.<name>.update` is set to <string>. Avoid these repetitive clauses by stating the command line options take precedence over configured options. Also add 'none' to the list of options instead of mentioning it in the following running text and split the list into two parts, one that is accessible via the command line and one that is only reachable via the configuration variables. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-12submodule documentation: add options to the subcommandLibravatar Stefan Beller1-16/+11
When reading up on a subcommand of `git submodule <subcommand>`, it is convenient to have its options nearby and not just at the top of the man page. Add the options to each subcommand. While at it, also document the `--checkout` option for `update`. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-12submodule: add absorb-git-dir functionLibravatar Stefan Beller1-0/+15
When a submodule has its git dir inside the working dir, the submodule support for checkout that we plan to add in a later patch will fail. Add functionality to migrate the git directory to be absorbed into the superprojects git directory. The newly added code in this patch is structured such that other areas of Git can also make use of it. The code in the submodule--helper is a mere wrapper and option parser for the function `absorb_git_dir_into_superproject`, that takes care of embedding the submodules git directory into the superprojects git dir. That function makes use of the more abstract function for this use case `relocate_gitdir`, which can be used by e.g. the worktree code eventually to move around a git directory. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-19submodules doc: update documentation for "." used for submodule branchesLibravatar Brandon Williams1-1/+3
4d7bc52b17 ("submodule update: allow '.' for branch value", 2016-08-03) adopted from Gerrit a feature to set "." as a special value of "submodule.<name>.branch" in .gitmodules file to indicate that the tracking branch in the submodule should be the same as the current branch in the superproject. Update the documentation to describe this. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-27submodule update: learn `--[no-]recommend-shallow` optionLibravatar Stefan Beller1-2/+9
Sometimes the history of a submodule is not considered important by the projects upstream. To make it easier for downstream users, allow a boolean field 'submodule.<name>.shallow' in .gitmodules, which can be used to recommend whether upstream considers the history important. This field is honored in the initial clone by default, it can be ignored by giving the `--no-recommend-shallow` option. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-17Merge branch 'sb/submodule-deinit-all'Libravatar Junio C Hamano1-6/+13
Correct faulty recommendation to use "git submodule deinit ." when de-initialising all submodules, which would result in a strange error message in a pathological corner case. * sb/submodule-deinit-all: submodule deinit: require '--all' instead of '.' for all submodules
2016-05-05submodule deinit: require '--all' instead of '.' for all submodulesLibravatar Stefan Beller1-6/+13
The discussion in [1] pointed out that '.' is a faulty suggestion as there is a corner case where it fails: > "submodule deinit ." may have "worked" in the sense that you would > have at least one path in your tree and avoided this "nothing > matches" most of the time. It would have still failed with the > exactly same error if run in an empty repository, i.e. > > $ E=/var/tmp/x/empty && rm -fr "$E" && mkdir -p "$E" && cd "$E" > $ git init > $ rungit v2.6.6 submodule deinit . > error: pathspec '.' did not match any file(s) known to git. > Did you forget to 'git add'? > $ >file && git add file > $ rungit v2.6.6 submodule deinit . > $ echo $? > 0 So instead of a pathspec add the '--all' option to deinit all submodules and add a test to check for the corner case of an empty repository. The code only needs to learn about the '--all' option and doesn't require further changes as `git submodule--helper list "$@"` will list all submodules when "$@" is empty. [1] http://news.gmane.org/gmane.comp.version-control.git/289535 Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-01submodule update: expose parallelism to the userLibravatar Stefan Beller1-1/+6
Expose possible parallelism either via the "--jobs" CLI parameter or the "submodule.fetchJobs" setting. By having the variable initialized to -1, we make sure 0 can be passed into the parallel processing machine, which will then pick as many parallel workers as there are CPUs. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-04document submodule sync --recursiveLibravatar Stefan Beller1-1/+4
The git-submodule(1) is inconsistent. In the synopsis, it says: git submodule [--quiet] sync [--recursive] [--] [<path>...] The description of the sync does not mention --recursive, and the description of --recursive says that it is only available for foreach, update and status. The option was introduced (82f49f294c, Teach --recursive to submodule sync, 2012-10-26) a while ago, so let's document it, too. Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-28submodule doc: reorder introductory paragraphsLibravatar Stefan Beller1-28/+22
It's better to start the man page with a description of what submodules actually are, instead of saying what they are not. Reorder the paragraphs such that - the first short paragraph introduces the submodule concept, - the second paragraph highlights the usage of the submodule command, - the third paragraph giving background information, and finally - the fourth paragraph discusing alternatives such as subtrees and remotes, which we don't want to be confused with. This ordering deepens the knowledge on submodules with each paragraph. First the basic questions like "How/what" will be answered, while the underlying concepts will be taught at a later time. Making sure it is not confused with subtrees and remotes is not really enhancing knowledge of submodules itself, but rather painting the big picture of git concepts, so you could also argue to have it as the second paragraph. Personally I think this may confuse readers, specially newcomers though. Additionally to reordering the paragraphs, they have been slightly reworded. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-02submodule: improve documentation of update subcommandLibravatar Michal Sojka1-20/+46
The documentation of 'git submodule update' has several problems: 1) It mentions that value 'none' of submodule.$name.update can be overridden by --checkout, but other combinations of configuration values and command line options are not mentioned. 2) The documentation of submodule.$name.update is scattered across three places, which is confusing. 3) The documentation of submodule.$name.update in gitmodules.txt is incorrect, because the code always uses the value from .git/config and never from .gitmodules. 4) Documentation of --force was incomplete, because it is only effective in case of checkout method of update. Fix all these problems by documenting submodule.*.update in git-submodule.txt and make everybody else refer to it. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-10Merge branch 'mc/doc-submodule-sync-recurse' into maintLibravatar Junio C Hamano1-1/+1
* mc/doc-submodule-sync-recurse: submodule: document "sync --recursive"
2014-06-13submodule: document "sync --recursive"Libravatar Matthew Chen1-1/+1
The "git submodule sync" command supports the --recursive flag, but the documentation does not mention this. That flag is useful, for example when a remote is changed in a submodule of a submodule. Signed-off-by: Matthew Chen <charlesmchen@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-02Revert "submodule: explicit local branch creation in module_clone"Libravatar Junio C Hamano1-26/+8
This reverts commit 23d25e48f5ead73c9ce233986f90791abec9f1e8, as it is broken for users who haven't opted into the new feature of checking out submodule.*.branch with update mode set to checkout.
2014-04-01Revert "Merge branch 'wt/doc-submodule-name-path-confusion-2'"Libravatar Junio C Hamano1-1/+1
This reverts commit 00d4ff1a69883e24b095f45251d99143b5bc0320, reversing changes made to d3badc6eb0961382788c2670129d5ee133d079fd.
2014-03-31Merge branch 'wt/doc-submodule-name-path-confusion-2'Libravatar Junio C Hamano1-1/+1
* wt/doc-submodule-name-path-confusion-2: doc: submodule.*.branch config is keyed by name
2014-03-31Merge branch 'wt/doc-submodule-name-path-confusion-1'Libravatar Junio C Hamano1-1/+1
* wt/doc-submodule-name-path-confusion-1: doc: submodule.* config are keyed by submodule names
2014-03-27doc: submodule.*.branch config is keyed by nameLibravatar W. Trevor King1-1/+1
Ever since 941987a5 (git-submodule: give submodules proper names, 2007-06-11) introduced the ability to move a submodule from one path to another inside its superproject tree without losing its identity, we should have consistently used submodule.<name>.* to access settings related to the named submodule. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27doc: submodule.* config are keyed by submodule namesLibravatar W. Trevor King1-1/+1
Ever since 941987a5 (git-submodule: give submodules proper names, 2007-06-11) introduced the ability to move a submodule from one path to another inside its superproject tree without losing its identity, we should have consistently used submodule.<name>.* to access settings related to the named submodule. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-14Merge branch 'jl/doc-submodule-update-checkout'Libravatar Junio C Hamano1-1/+10
Add missing documentation for "submodule update --checkout". * jl/doc-submodule-update-checkout: submodule update: consistently document the '--checkout' option
2014-02-28submodule update: consistently document the '--checkout' optionLibravatar Jens Lehmann1-1/+10
Commit 322bb6e12f (add update 'none' flag to disable update of submodule by default) added the '--checkout' option to "git submodule update" but forgot to explicitly document it in synopsis, usage string and man page (It is only mentioned implicitly in the man page). In 23d25e48 (submodule: explicit local branch creation in module_clone) the synopsis of the man page was updated, but the "OPTIONS" section of the man page and the usage string of the git-submodule script still do not mention the '--checkout' option. Fix that by documenting this option in usage string and the "OPTIONS" section of man page too. While at it group the update-mode options into a single set in the usage string. Reported-by: Matthijs Kooijman <matthijs@stdin.nl> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24Documentation: describe 'submodule update --remote' use caseLibravatar W. Trevor King1-0/+10
Make it clear that there is no implicit floating going on; --remote lets you explicitly integrate the upstream branch in your current HEAD (just like running 'git pull' in the submodule). The only distinction with the current 'git pull' is the config location and setting used for the upstream branch, which is hopefully clear now. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24submodule: explicit local branch creation in module_cloneLibravatar W. Trevor King1-9/+27
The previous code only checked out branches in cmd_add. This commit moves the branch-checkout logic into module_clone, where it can be shared by cmd_add and cmd_update. I also update the initial checkout command to use 'reset' to preserve branches setup during module_clone. With this change, folks cloning submodules for the first time via: $ git submodule update ... will get a local branch instead of a detached HEAD, unless they are using the default checkout-mode updates. This is a change from the previous situation where cmd_update always used checkout-mode logic (regardless of the requested update mode) for updates that triggered an initial clone, which always resulted in a detached HEAD. This commit does not change the logic for updates after the initial clone, which will continue to create detached HEADs for checkout-mode updates, and integrate remote work with the local HEAD (detached or not) in other modes. The motivation for the change is that developers doing local work inside the submodule are likely to select a non-checkout-mode for updates so their local work is integrated with upstream work. Developers who are not doing local submodule work stick with checkout-mode updates so any apparently local work is blown away during updates. For example, if upstream rolls back the remote branch or gitlinked commit to an earlier version, the checkout-mode developer wants their old submodule checkout to be rolled back as well, instead of getting a no-op merge/rebase with the rolled-back reference. By using the update mode to distinguish submodule developers from black-box submodule consumers, we can setup local branches for the developers who will want local branches, and stick with detached HEADs for the developers that don't care. Testing ======= In t7406, just-cloned checkouts now update to the gitlinked hash with 'reset', to preserve the local branch for situations where we're not on a detached HEAD. I also added explicit tests to t7406 for HEAD attachement after cloning updates, showing that it depends on their update mode: * Checkout-mode updates get detached HEADs * Everyone else gets a local branch, matching the configured submodule.<name>.branch and defaulting to master. The 'initial-setup' tag makes it easy to reset the superproject to a known state, as several earlier tests commit to submodules and commit the changed gitlinks to the superproject, but don't push the new submodule commits to the upstream subprojects. This makes it impossible to checkout the current super master, because it references submodule commits that don't exist in the upstream subprojects. For a specific example, see the tests that currently generate the 'two_new_submodule_commits' commits. Documentation ============= I updated the docs to describe the 'submodule update' modes in detail. The old documentation did not distinguish between cloning and non-cloning updates and lacked clarity on which operations would lead to detached HEADs, and which would not. The new documentation addresses these issues while updating the docs to reflect the changes introduced by this commit's explicit local branch creation in module_clone. I also add '--checkout' to the usage summary and group the update-mode options into a single set. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15Merge branch 'fg/submodule-clone-depth'Libravatar Junio C Hamano1-2/+8
Allow shallow-cloning of submodules with "git submodule update". * fg/submodule-clone-depth: Add --depth to submodule update/add
2013-07-15Merge branch 'cp/submodule-custom-update'Libravatar Junio C Hamano1-1/+3
In addition to the choice from "rebase, merge, or checkout-detach", allow a custom command to be used in "submodule update" to update the working tree of submodules. * cp/submodule-custom-update: submodule update: allow custom command to update submodule working tree
2013-07-03Change "remote tracking" to "remote-tracking"Libravatar Michael Schubert1-1/+1
Fix a typo ("remote remote-tracking") going back to the big cleanup in 2010 (8b3f3f84 etc). Also, remove some more occurrences of "tracking" and "remote tracking" in favor of "remote-tracking". Signed-off-by: Michael Schubert <mschub@elegosoft.com> Reviewed-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03Add --depth to submodule update/addLibravatar Fredrik Gustafsson1-2/+8
Add the --depth option to the add and update commands of "git submodule", which is then passed on to the clone command. This is useful when the submodule(s) are huge and you're not really interested in anything but the latest commit. Tests are added and some indention adjustments were made to conform to the rest of the testfile on "submodule update can handle symbolic links in pwd". Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03submodule update: allow custom command to update submodule working treeLibravatar Chris Packham1-1/+3
Users can set submodule.$name.update to '!command' which will cause 'command' to be run instead of checkout/merge/rebase. This allows the user finer-grained control over how the update is done. The primary motivation for this was interoperability with stgit; however being able to intercept the submodule update process may prove useful for integrating with or extending other tools. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16git-submodule.txt: Clarify 'init' and 'add' subcommands.Libravatar Dale R. Worley1-2/+6
Describe how 'add' sets the submodule's logical name, which is used in the configuration entry names. Clarify that 'init' only sets up the configuration entries for submodules that have already been added elsewhere. Describe that <path> arguments limit the submodules that are configured. Signed-off-by: Dale Worley <worley@ariadne.com> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25Merge branch 'jl/submodule-deinit'Libravatar Junio C Hamano1-1/+17
There was no Porcelain way to say "I no longer am interested in this submodule", once you express your interest in a submodule with "submodule init". "submodule deinit" is the way to do so. * jl/submodule-deinit: submodule: add 'deinit' command
2013-03-04submodule: add 'deinit' commandLibravatar Jens Lehmann1-1/+17
With "git submodule init" the user is able to tell git he cares about one or more submodules and wants to have it populated on the next call to "git submodule update". But currently there is no easy way he could tell git he does not care about a submodule anymore and wants to get rid of his local work tree (except he knows a lot about submodule internals and removes the "submodule.$name.url" setting from .git/config together with the work tree himself). Help those users by providing a 'deinit' command. This removes the whole submodule.<name> section from .git/config (either for the given submodule(s) or for all those which have been initialized if '.' is used) together with their work tree. Fail if the current work tree contains modifications (unless forced), but don't complain when either the work tree is already removed or no settings are found in .git/config. Add tests and link the man pages of "git submodule deinit" and "git rm" to assist the user in deciding whether removing or unregistering the submodule is the right thing to do for him. Also add the deinit subcommand to the completion list. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-27Merge branch 'maint'Libravatar Junio C Hamano1-2/+3
* maint: Update draft release notes to 1.8.1.5 Documentation/submodule: Add --force to update synopsis
2013-02-27Documentation/submodule: Add --force to update synopsisLibravatar Brad King1-1/+1
In commit 9db31bdf (submodule: Add --force option for git submodule update, 2011-04-01) we added the option to the implementation's usage synopsis but forgot to add it to the synopsis in the command documentation. Add the option to the synopsis in the same location it is reported in usage and re-wrap the options to avoid long lines. Signed-off-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19submodule add: If --branch is given, record it in .gitmodulesLibravatar W. Trevor King1-0/+2
This allows you to easily record a submodule.<name>.branch option in .gitmodules when you add a new submodule. With this patch, $ git submodule add -b <branch> <repository> [<path>] $ git config -f .gitmodules submodule.<path>.branch <branch> reduces to $ git submodule add -b <branch> <repository> [<path>] This means that future calls to $ git submodule update --remote ... will get updates from the same branch that you used to initialize the submodule, which is usually what you want. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19submodule update: add --remote for submodule's upstream changesLibravatar W. Trevor King1-1/+22
The current `update` command incorporates the superproject's gitlinked SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the options you use, it may checkout $sha1, rebase the $subsha1 onto $sha1, or merge $sha1 into $subsha1. This helps you keep up with changes in the upstream superproject. However, it's also useful to stay up to date with changes in the upstream subproject. Previous workflows for incorporating such changes include the ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With this patch, all of the useful functionality for incorporating superproject changes can be reused to incorporate upstream subproject updates. When you specify --remote, the target $sha1 is replaced with a $sha1 of the submodule's origin/master tracking branch. If you want to merge a different tracking branch, you can configure the `submodule.<name>.branch` option in `.gitmodules`. You can override the `.gitmodules` configuration setting for a particular superproject by configuring the option in that superproject's default configuration (using the usual configuration hierarchy, e.g. `.git/config`, `~/.gitconfig`, etc.). Previous use of submodule.<name>.branch ======================================= Because we're adding a new configuration option, it's a good idea to check if anyone else is already using the option. The foreach-pull example above was described by Ævar in commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Fri May 21 16:10:10 2010 +0000 git-submodule foreach: Add $toplevel variable Gerrit uses the same interpretation for the setting, but because Gerrit has direct access to the subproject repositories, it updates the superproject repositories automatically when a subproject changes. Gerrit also accepts the special value '.', which it expands into the superproject's branch name. Although the --remote functionality is using `submodule.<name>.branch` slightly differently, the effect is the same. The foreach-pull example uses the option to record the name of the local branch to checkout before pulls. The tracking branch to be pulled is recorded in `.git/modules/<name>/config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule.<name>.branch` was likely the same as the branch name used during the initial `submodule add`, the same branch will be pulled in each workflow. Implementation details ====================== In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. However, I didn't change the logic guarding the existing fetch: if test -z "$nofetch" then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$path" && ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && test -z "$rev") || git-fetch)) || die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" fi There will not be a double-fetch, because the new $sha1 determined after the `--remote` triggered fetch should always exist in the repository. If it doesn't, it's because some racy process removed it from the submodule's repository and we *should* be re-fetching. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-21Merge branch 'wtk/submodule-doc-fixup'Libravatar Junio C Hamano1-1/+1
* wtk/submodule-doc-fixup: git-submodule: wrap branch option with "<>" in usage strings.
2012-10-29Merge branch 'jl/submodule-add-by-name'Libravatar Jeff King1-1/+6
If you remove a submodule, in order to keep the repository so that "git checkout" to an older commit in the superproject history can resurrect the submodule, the real repository will stay in $GIT_DIR of the superproject. A later "git submodule add $path" to add a different submodule at the same path will fail. Diagnose this case a bit better, and if the user really wants to add an unrelated submodule at the same path, give the "--name" option to give it a place in $GIT_DIR of the superproject that does not conflict with the original submodule. * jl/submodule-add-by-name: submodule add: Fail when .git/modules/<name> already exists unless forced Teach "git submodule add" the --name option
2012-10-25git-submodule: wrap branch option with "<>" in usage strings.Libravatar W. Trevor King1-1/+1
Use "-b <branch>" instead of "-b branch". This brings the usage strings in line with other options, e.g. "--reference <repository>". Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Jeff King <peff@peff.net>
2012-09-29Teach "git submodule add" the --name optionLibravatar Jens Lehmann1-1/+6
"git submodule add" initializes the name of a submodule to its path. This was ok as long as the .git directory lived inside the submodule's work tree, but since 1.7.8 it is stored in the .git/modules/<name> directory of the superproject, making the submodule name survive the removal of the submodule's work tree. This leads to problems when the user tries to add a different submodule at the same path - and thus the same name - later, as that will happily try to restore the submodule from the old repository instead of the one the user specified and will lead to a checkout of the wrong repository. Add the new "--name" option to let the user provide a name for the submodule. This enables the user to solve this conflict without having to remove .git/modules/<name> by hand (which is no viable solution as it makes it impossible to checkout a commit that records the old submodule and populate it, as that will still check out the new submodule for the same reason). To achieve that the submodule's name is added to the parameter list of the module_clone() helper function. This makes it possible to remove the call of module_name() there because both callers of module_clone() already know the name and can provide it as argument number two. Reported-by: Jonathan Johnson <me@jondavidjohn.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-25submodule: if $command was not matched, don't parse other argsLibravatar Ramkumar Ramachandra1-1/+0
"git submodule" command DWIMs the command line and assumes a unspecified action word for 'status' action. This is a UI mistake that leads to a confusing behaviour. A mistyped command name is instead treated as a request for 'status' of the submodule with that name, e.g. $ git submodule show error: pathspec 'show' did not match any file(s) known to git. Did you forget to 'git add'? Stop DWIMming an unknown or mistyped subcommand name as pathspec given to unspelled "status" subcommand. "git submodule" without any argument is still interpreted as "git submodule status", but its value is questionable. Adjust t7400 to match, and stop advertising the default subcommand being 'status' which does not help much in practice, other than promoting laziness and confusion. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>