git/Documentation/gitmodules.txt, branch v2.0.0

Revert "submodule: explicit local branch creation in module_clone"

2014-04-02T21:15:36Z

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.

Merge branch 'wk/submodule-on-branch'

2014-02-27T22:01:33Z

Make sure 'submodule update' modes that do not detach HEADs can be used more pleasantly by checking out a concrete branch when cloning them to prime the well. * wk/submodule-on-branch: Documentation: describe 'submodule update --remote' use case submodule: explicit local branch creation in module_clone submodule: document module_clone arguments in comments submodule: make 'checkout' update_module mode more explicit

submodule: explicit local branch creation in module_clone

2014-02-24T22:35:48Z

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..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 Signed-off-by: Junio C Hamano

Documentation/gitmodules: Only 'update' and 'url' are required

2014-01-06T17:08:18Z

Descriptions for all the settings fell under the initial "Each submodule section also contains the following required keys:". The example shows sections with just 'path' and 'url' entries, which are indeed required, but we should still make the required/optional distinction explicit to clarify that the rest of them are optional. Signed-off-by: W. Trevor King Reviewed-by: Heiko Voigt Signed-off-by: Junio C Hamano

Improve documentation concerning the status.submodulesummary setting

2013-09-11T19:20:41Z

'git status' and 'git commit' can be told to also show the output of "git submodule summary" by setting the "status.submodulesummary" config option. But status and commit also honor the "diff.ignoreSubmodules" and the "submodule..ignore" settings, which then disable the summary partly or completely. This - and the fact that the last two settings do not affect the "git submodule" commands at all - is not well documented. Extend the documentation in those places where "status.submodulesummary", "diff.ignoreSubmodules" and "submodule..ignore" are described to better explain these dependencies. Thanks-to: Matthieu Moy Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

Documentation: the name of the system is 'Git', not 'git'

2013-02-01T21:53:33Z

Signed-off-by: Thomas Ackermann Signed-off-by: Junio C Hamano

submodule update: add --remote for submodule's upstream changes

2012-12-19T17:40:01Z

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..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..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 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..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//config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule..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 Signed-off-by: Junio C Hamano

Teach "git submodule add" the --name option

2012-09-30T04:49:11Z

"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/ 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/ 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 Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

document submdule.$name.update=none option for gitmodules

2012-05-11T15:39:33Z

This option was not yet described in the gitmodules documentation. We only described it in the 'git submodule' command documentation but gitmodules is the more natural place to look. A short reference in the 'git submodule' documentation should be sufficient since the details can now be found in the documentation to gitmodules. Signed-off-by: Heiko Voigt Signed-off-by: Junio C Hamano

correct spelling: an URL -> a URL

2012-03-28T15:47:23Z

Signed-off-by: Jim Meyering Signed-off-by: Junio C Hamano