user/sven/git.git/t/t7400-submodule-basic.sh, branch v1.8.0.2

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

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

submodule: document failure to handle relative superproject origin URLs

2012-06-03T21:35:09Z

This test case documents several cases where handling of relative superproject origin URLs doesn't produce an expected result. submodule.{sub}.url in the superproject is incorrect in these cases: foo ./foo ./foo/bar The remote.origin.url of the submodule is incorrect in the above cases and also when the superproject origin URL is like: foo/bar ../foo ../foo/bar Signed-off-by: Jon Seymour Signed-off-by: Junio C Hamano

submodule: additional regression tests for relative URLs

2012-06-03T21:34:47Z

Some additional tests are added to support regression testing of the changes in the remainder of the series. We also add a pristine copy of .gitmodules in anticipation of this being required by later tests. Signed-off-by: Jon Seymour Signed-off-by: Junio C Hamano

tests: modernise style: more uses of test_line_count

2012-04-11T16:32:20Z

Prefer: test_line_count COUNT FILE over: test $(wc -l COUNT (or similar usages) in several tests. Signed-off-by: Stefano Lattarini Signed-off-by: Junio C Hamano

submodules: always use a relative path from gitdir to work tree

2012-03-05T05:20:27Z

Since recently a submodule with name has its git directory in the .git/modules/ directory of the superproject while the work tree contains a gitfile pointing there. To make that work the git directory has the core.worktree configuration set in its config file to point back to the work tree. That core.worktree is an absolute path set by the initial clone of the submodule. A relative path is preferable here because it allows the superproject to be moved around without invalidating that setting, so compute and set that relative path after cloning or reactivating the submodule. This also fixes a bug when moving a submodule around inside the superproject, as the current code forgot to update the setting to the new submodule work tree location. Enhance t7400 to ensure that future versions won't re-add absolute paths by accident and that moving a superproject won't break submodules. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano