git/t/t7400-submodule-basic.sh, branch v1.8.2.2

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

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

submodule add: Fail when .git/modules/ already exists unless forced

2012-09-30T23:53:57Z

When adding a new submodule it can happen that .git/modules/ already contains a submodule repo, e.g. when a submodule is removed from the work tree and another submodule is added at the same path. But then the work tree of the submodule will be populated using the existing repository and not the one the user provided, which results in an incorrect work tree. On the other hand the user might reactivate a submodule removed earlier, then reusing that .git directory is the Right Thing to do. As git can't decide what is the case, error out and tell the user she should use either use a different name for the submodule with the "--name" option or can reuse the .git directory for the newly added submodule by providing the --force option (which only makes sense when the upstream matches, so the error message lists all remotes of .git/modules/). In one test in t7406 the --force option had to be added to "git submodule add", as that test re-adds a formerly removed submodule. Reported-by: Jonathan Johnson Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

Merge branch 'rr/maint-submodule-unknown-cmd'

2012-09-30T05:28:33Z

* rr/maint-submodule-unknown-cmd: submodule: if $command was not matched, don't parse other args

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

Merge branch 'hv/submodule-path-unmatch'

2012-08-29T21:50:15Z

* hv/submodule-path-unmatch: Let submodule command exit with error status if path does not exist

Let submodule command exit with error status if path does not exist

2012-08-14T21:00:17Z

Various subcommands of the "git submodule" command exited with 0 status even though the path given by the user did not exist. The reason behind that was that they all pipe the output of module_list into the while loop which then does the action on the paths specified by the commandline. Since the exit code of the command on the upstream side of the pipe is ignored by the shell, the status code of "ls-files --error-unmatch" nor "module_list" was not propagated. In case ls-files returns with an error code, we write a special string that is not possible in non error situations, and no other output, so that the downstream can detect the error and die with an error code. The error message that there is an unmatched pathspec comes through stderr directly from ls-files. So the user still gets a hint whats going on. Signed-off-by: Heiko Voigt Signed-off-by: Junio C Hamano

t7400: avoid path mangling issues

2012-06-14T18:00:06Z

A recently introduced test uses an absolute path. But when run on Windows using the MSYS bash, such a path is mangled into a Windows style path when it is passed to 'git config'. The subsequent 'test' then compares the mangled path to the unmangled version and reports a failure. A path beginning with two slashes denotes a network directory (//server/share path) and is not mangled. Use that trick to side-step the issue. Just in case that 'git submodule init' regresses in such a way that it accesses the URL, use a path name that is unlikely to exist on POSIX systems, and that cannot be a server name on Windows. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

submodule: fix handling of superproject origin URLs like foo, ./foo and ./foo/bar

2012-06-06T18:43:55Z

Currently git submodule init and git submodule sync fail with an error if the superproject origin URL is of the form foo but succeed if the superproject origin URL is of the form ./foo or ./foo/bar or foo/bar. This change makes handling of the foo case behave like the handling of the ./foo case and also ensures that superfluous leading and embedded ./'s are removed from the resulting derived URLs. Signed-off-by: Jon Seymour Signed-off-by: Junio C Hamano