git/Documentation/git-submodule.txt, branch v1.8.2.2

Merge branch 'maint'

2013-02-27T18:10:28Z

* maint: Update draft release notes to 1.8.1.5 Documentation/submodule: Add --force to update synopsis

Documentation/submodule: Add --force to update synopsis

2013-02-27T15:31:01Z

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 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 add: If --branch is given, record it in .gitmodules

2012-12-19T17:40:51Z

This allows you to easily record a submodule..branch option in .gitmodules when you add a new submodule. With this patch, $ git submodule add -b [] $ git config -f .gitmodules submodule..branch reduces to $ git submodule add -b [] 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 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

Merge branch 'wtk/submodule-doc-fixup'

2012-11-21T21:25:42Z

* wtk/submodule-doc-fixup: git-submodule: wrap branch option with "<>" in usage strings.

Merge branch 'jl/submodule-add-by-name'

2012-10-29T08:12:12Z

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/ already exists unless forced Teach "git submodule add" the --name option

git-submodule: wrap branch option with "<>" in usage strings.

2012-10-25T08:46:13Z

Use "-b " instead of "-b branch". This brings the usage strings in line with other options, e.g. "--reference ". Signed-off-by: W. Trevor King Signed-off-by: Jeff King

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

submodule: if $command was not matched, don't parse other args

2012-09-25T18:31:48Z

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