user/sven/git.git/git-submodule.sh, branch v1.7.6.3

Merge branch 'jl/submodule-update-quiet' into maint

2011-08-16T19:41:14Z

* jl/submodule-update-quiet: submodule: update and add must honor --quiet flag

Merge branch 'jl/submodule-add-relurl-wo-upstream' into maint

2011-08-16T19:41:13Z

* jl/submodule-add-relurl-wo-upstream: submodule add: clean up duplicated code submodule add: allow relative repository path even when no url is set submodule add: test failure when url is not configured in superproject Conflicts: git-submodule.sh

Merge branch 'jc/submodule-sync-no-auto-vivify' into maint

2011-08-16T18:41:26Z

* jc/submodule-sync-no-auto-vivify: submodule add: always initialize .git/config entry submodule sync: do not auto-vivify uninteresting submodule

Merge branch 'bc/submodule-foreach-stdin-fix-1.7.4' into maint

2011-08-16T18:23:26Z

* bc/submodule-foreach-stdin-fix-1.7.4: git-submodule.sh: preserve stdin for the command spawned by foreach t/t7407: demonstrate that the command called by 'submodule foreach' loses stdin

submodule: update and add must honor --quiet flag

2011-07-28T19:48:26Z

When using the --quiet flag "git submodule update" and "git submodule add" didn't behave as the documentation stated. They printed progress output from the clone, even though they should only print error messages. Fix that by passing the -q flag to git clone in module_clone() when the GIT_QUIET variable is set. Two tests in t7400 have been modified to test that behavior. Reported-by: Daniel Holtmann-Rice Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

git-submodule.sh: preserve stdin for the command spawned by foreach

2011-06-30T01:25:49Z

The user-supplied command spawned by 'submodule foreach' loses its connection to the original standard input. Instead, it is connected to the output of a pipe within the git-submodule script. The user-supplied command supplied to 'submodule foreach' is spawned within a while loop which is being piped into. Due to the way shells implement piping output to a while loop, a subshell is created with its standard input attached to the output of the pipe. This results in all of the commands executed within the while loop to have their stdins modified in the same way, including the user-supplied command. This can cause a problem if the command requires reading from stdin or if it changes its behavior based on whether stdin is a tty or not. For example, this problem was noticed when trying to execute the following: git submodule foreach git shortlog --since=two.weeks.ago which printed a message about entering the first submodule and produced no further output and exited with a status of zero. In this case, shortlog detected that it was not connected to a tty, and since no revision was supplied as an argument, it attempted to read the list of revisions from standard input. Instead, it slurped up the list of submodules that was being piped to the enclosing while loop and caused that loop to end early without processing the remaining submodules. Work around this behavior by saving the original standard input file descriptor before the while loop, and restoring it when spawning the user-supplied command. This fixes the tests in t7407. Signed-off-by: Brandon Casey Signed-off-by: Junio C Hamano

submodule add: always initialize .git/config entry

2011-06-26T20:15:21Z

When "git submodule add $path" is run to add a subdirectory $path to the superproject, and $path is already the top of the working tree of the submodule repository, the command created submodule.$path.url entry in the configuration file in the superproject. However, when adding a repository $URL that is outside the respository of the superproject to $path that does not exist (yet) with "git submodule add $URL $path", the command forgot to set it up. The user is expressing the interest in the submodule and wants to keep a checkout, the "submodule add" command should consistently set up the submodule.$path.url entry in either case. As a result "git submodule init" can't simply skip the initialization of those submodules for which it finds an url entry in the git./config anymore. That lead to problems when adding a submodule (which now sets the url), add the "update" setting to .gitmodules and expect init to copy that into .git/config like it is done in t7406. So change init to only then copy the "url" and "update" entries when they don't exist yet in the .git/config and do nothing otherwise. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

submodule sync: do not auto-vivify uninteresting submodule

2011-06-26T20:06:08Z

Earlier 33f072f (submodule sync: Update "submodule..url" for empty directories, 2010-10-08) attempted to fix a bug where "git submodule sync" command does not update the URL if the current superproject does not have a checkout of the submodule. However, it did so by unconditionally registering submodule.$name.url to every submodule in the project, even the ones that the user has never showed interest in at all by running 'git submodule init' command. This caused subsequent 'git submodule update' to start cloning/updating submodules that are not interesting to the user at all. Update the code so that the URL is updated from the .gitmodules file only for submodules that already have submodule.$name.url entries, i.e. the ones the user has showed interested in having a checkout. Acked-by: Jens Lehmann Signed-off-by: Junio C Hamano

submodule add: clean up duplicated code

2011-06-06T20:46:36Z

In cmd_add() the switch statement used to resolve a relative url was present twice. Remove the second one and use the realrepo variable set by the first one (lines 194 ff.) instead. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

submodule add: allow relative repository path even when no url is set

2011-06-06T20:46:36Z

Adding a submodule with a relative repository path did only succeed when the superproject's default remote was set. But when that is unset, the superproject is its own authoritative upstream, so lets use its working directory as upstream instead. This allows users to set up a new superpoject where the submodules urls are configured relative to the superproject's upstream while its default remote can be configured later. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano