git/git-submodule.sh, branch v2.29.2

Merge branch 'td/submodule-update-quiet'

2020-10-05T21:01:53Z

"git submodule update --quiet" did not squelch underlying "rebase" and "pull" commands. * td/submodule-update-quiet: submodule update: silence underlying merge/rebase with "--quiet"

submodule update: silence underlying merge/rebase with "--quiet"

2020-10-01T15:50:24Z

Commands such as $ git pull --rebase --recurse-submodules --quiet produce non-quiet output from the merge or rebase. Pass the --quiet option down when invoking "rebase" and "merge". Also fix the parsing of git submodule update -v. When e84c3cf3 (git-submodule.sh: accept verbose flag in cmd_update to be non-quiet, 2018-08-14) taught "git submodule update" to take "--quiet", it apparently did not know how ${GIT_QUIET:+--quiet} works, and reviewers seem to have missed that setting the variable to "0", rather than unsetting it, still results in "--quiet" being passed to underlying commands. Signed-off-by: Theodore Dubois Signed-off-by: Junio C Hamano

submodule: port submodule subcommand 'summary' from shell to C

2020-08-12T21:12:58Z

Convert submodule subcommand 'summary' to a builtin and call it via 'git-submodule.sh'. The shell version had to call $diff_cmd twice, once to find the modified modules cared by the user and then again, with that list of modules to do various operations for computing the summary of those modules. On the other hand, the C version does not need a second call to $diff_cmd since it reuses the module list from the first call to do the aforementioned tasks. In the C version, we use the combination of setting a child process' working directory to the submodule path and then calling 'prepare_submodule_repo_env()' which also sets the 'GIT_DIR' to '.git', so that we can be certain that those spawned processes will not access the superproject's ODB by mistake. A behavioural difference between the C and the shell version is that the shell version outputs two line feeds after the 'git log' output when run outside of the tests while the C version outputs one line feed in any case. The reason for this is that the shell version calls log with '--pretty=format:' whose output is followed by two echo calls; 'format' does not have "terminator" semantics like its 'tformat' counterpart. So, the log output is terminated by a newline only when invoked by the user and not when invoked from the scripts. This results in the one & two line feed differences in the shell version. On the other hand, the C version calls log with '--pretty=' which is equivalent to '--pretty:tformat:' which is then followed by a 'printf("\n")'. Due to its "terminator" semantics the log output is always terminated by newline and hence one line feed in any case. Also, when we try to pass an option-like argument after a non-option argument, for instance: git submodule summary HEAD --foo-bar (or) git submodule summary HEAD --cached That argument would be treated like a path to the submodule for which the user is requesting a summary. So, the option ends up having no effect. Though, passing '--quiet' is an exception to this: git submodule summary HEAD --quiet While 'summary' doesn't support '--quiet', we don't get an output for the above command as '--quiet' is treated as a path which means we get an output only if a submodule whose path is '--quiet' exists. The error message in case of computing a summary for non-existent submodules in the C version is different from that of the shell version. Since the new error message is not marked for translation, change the 'test_i18ngrep' in t7421.4 to 'grep'. Mentored-by: Christian Couder Mentored-by: Stefan Beller Mentored-by: Kaartic Sivaraam Helped-by: Johannes Schindelin Signed-off-by: Prathamesh Chavan Signed-off-by: Shourya Shukla Signed-off-by: Junio C Hamano

submodule: port subcommand 'set-branch' from shell to C

2020-06-02T17:51:54Z

Convert submodule subcommand 'set-branch' to a builtin and call it via 'git-submodule.sh'. Mentored-by: Christian Couder Mentored-by: Kaartic Sivaraam Helped-by: Denton Liu Helped-by: Eric Sunshine Helped-by: Đoàn Trần Công Danh Signed-off-by: Shourya Shukla Signed-off-by: Junio C Hamano

submodule: port subcommand 'set-url' from shell to C

2020-05-08T16:17:55Z

Convert submodule subcommand 'set-url' to a builtin. Port 'set-url' to 'submodule--helper.c' and call the latter via 'git-submodule.sh'. Signed-off-by: Shourya Shukla Signed-off-by: Junio C Hamano

Merge branch 'lx/submodule-clear-variables'

2020-04-28T22:49:59Z

The "git submodule" command did not initialize a few variables it internally uses and was affected by variable settings leaked from the environment. * lx/submodule-clear-variables: git-submodule.sh: setup uninitialized variables

git-submodule.sh: setup uninitialized variables

2020-04-02T18:19:33Z

We have an environment variable `jobs=16` defined in our CI system, and this environment makes our build job failed with the following message: error: pathspec '16' did not match any file(s) known to git The pathspec '16' for Git command is from the environment variable "jobs". This is because "git-submodule" command is implemented in shell script, and environment variables may change its behavior. Set values for uninitialized variables, such as "jobs" and "recommend_shallow" will fix this issue. Helped-by: Jiang Xin Signed-off-by: Li Xuejiang Signed-off-by: Junio C Hamano

Merge branch 'es/recursive-single-branch-clone'

2020-03-05T18:43:03Z

"git clone --recurse-submodules --single-branch" now uses the same single-branch option when cloning the submodules. * es/recursive-single-branch-clone: clone: pass --single-branch during --recurse-submodules submodule--helper: use C99 named initializer

clone: pass --single-branch during --recurse-submodules

2020-02-25T18:00:38Z

Previously, performing "git clone --recurse-submodules --single-branch" resulted in submodules cloning all branches even though the superproject cloned only one branch. Pipe --single-branch through the submodule helper framework to make it to 'clone' later on. Signed-off-by: Emily Shaffer Acked-by: Jeff King Signed-off-by: Junio C Hamano

submodule add: show 'add --dry-run' stderr when aborting

2020-01-15T18:22:24Z

Unless --force is specified, 'submodule add' checks if the destination path is ignored by calling 'git add --dry-run --ignore-missing', and, if that call fails, aborts with a custom "path is ignored" message (a slight variant of what 'git add' shows). Aborting early rather than letting the downstream 'git add' call fail is done so that the command exits before cloning into the destination path. However, in rare cases where the dry-run call fails for a reason other than the path being ignored---for example, due to a preexisting index.lock file---displaying the "ignored path" error message hides the real source of the failure. Instead of displaying the tailored "ignored path" message, let's report the standard error from the dry run to give the caller more accurate information about failures that are not due to an ignored path. For the ignored path case, this leads to the following change in the error message: The following [-path is-]{+paths are+} ignored by one of your .gitignore files: Use -f if you really want to add [-it.-]{+them.+} The new phrasing is a bit awkward, because 'submodule add' is only dealing with one destination path. Alternatively, we could continue to use the tailored message when the exit code is 1 (the expected status for a failure due to an ignored path) and relay the standard error for all other non-zero exits. That, however, risks hiding the message of unrelated failures that share an exit code of 1, so it doesn't seem worth doing just to avoid a clunkier, but still clear, error message. Signed-off-by: Kyle Meyer Signed-off-by: Junio C Hamano