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

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

2017-10-07T08:52:35Z

This aims to make git-submodule 'status' a built-in. Hence, the function cmd_status() is ported from shell to C. This is done by introducing four functions: module_status(), submodule_status_cb(), submodule_status() and print_status(). The function module_status() acts as the front-end of the subcommand. It parses subcommand's options and then calls the function module_list_compute() for computing the list of submodules. Then this functions calls for_each_listed_submodule() looping through the list obtained. Then for_each_listed_submodule() calls submodule_status_cb() for each of the submodule in its list. The function submodule_status_cb() calls submodule_status() after passing appropriate arguments to the funciton. Function submodule_status() is responsible for generating the status each submodule it is called for, and then calls print_status(). Finally, the function print_status() handles the printing of submodule's status. Function set_name_rev() is also ported from git-submodule to the submodule--helper builtin function compute_rev_name(), which now generates the value of the revision name as required. Mentored-by: Christian Couder Mentored-by: Stefan Beller Signed-off-by: Prathamesh Chavan Signed-off-by: Junio C Hamano

Merge branch 'sb/submodule-parallel-update'

2017-08-23T21:13:14Z

Code clean-up. * sb/submodule-parallel-update: submodule.sh: remove unused variable

submodule.sh: remove unused variable

2017-08-17T18:05:49Z

This could have been part of 48308681b0 (git submodule update: have a dedicated helper for cloning, 2016-02-29). Signed-off-by: Stefan Beller Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

scripts: use "git foo" not "git-foo"

2017-08-07T19:04:45Z

We want to make sure that people who copy & paste code would see fewer instances of "git-foo". The use of these dashed forms have been discouraged since v1.6.0 days. Signed-off-by: Michael Forney Signed-off-by: Junio C Hamano

add: warn when adding an embedded repository

2017-06-15T16:10:44Z

It's an easy mistake to add a repository inside another repository, like: git clone $url git add . The resulting entry is a gitlink, but there's no matching .gitmodules entry. Trying to use "submodule init" (or clone with --recursive) doesn't do anything useful. Prior to v2.13, such an entry caused git-submodule to barf entirely. In v2.13, the entry is considered "inactive" and quietly ignored. Either way, no clone of your repository can do anything useful with the gitlink without the user manually adding the submodule config. In most cases, the user probably meant to either add a real submodule, or they forgot to put the embedded repository in their .gitignore file. Let's issue a warning when we see this case. There are a few things to note: - the warning will go in the git-add porcelain; anybody wanting to do low-level manipulation of the index is welcome to create whatever funny states they want. - we detect the case by looking for a newly added gitlink; updates via "git add submodule" are perfectly reasonable, and this avoids us having to investigate .gitmodules entirely - there's a command-line option to suppress the warning. This is needed for git-submodule itself (which adds the entry before adding any submodule config), but also provides a mechanism for other scripts doing submodule-like things. We could make this a hard error instead of a warning. However, we do add lots of sub-repos in our test suite. It's not _wrong_ to do so. It just creates a state where users may be surprised. Pointing them in the right direction with a gentle hint is probably the best option. There is a config knob that can disable the (long) hint. But I intentionally omitted a config knob to disable the warning entirely. Whether the warning is sensible or not is generally about context, not about the user's preferences. If there's a tool or workflow that adds gitlinks without matching .gitmodules, it should probably be taught about the new command-line option, rather than blanket-disabling the warning. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

submodule: prevent backslash expantion in submodule names

2017-04-17T03:09:36Z

When attempting to add a submodule with backslashes in its name 'git submodule' fails in a funny way. We can see that some of the backslashes are expanded resulting in a bogus path: git -C main submodule add ../sub\\with\\backslash fatal: repository '/tmp/test/sub\witackslash' does not exist fatal: clone of '/tmp/test/sub\witackslash' into submodule path To solve this, convert calls to 'read' to 'read -r' in git-submodule.sh in order to prevent backslash expantion in submodule names. Reported-by: Joachim Durchholz Signed-off-by: Brandon Williams Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

submodule add: respect submodule.active and submodule..active

2017-03-18T16:51:23Z

In addition to adding submodule..url to the config, set submodule..active to true unless submodule.active is configured and the submodule's path matches the configured pathspec. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

submodule sync: use submodule--helper is-active

2017-03-17T18:06:09Z

Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

submodule sync: skip work for inactive submodules

2017-03-17T18:06:09Z

Sync does some work determining what URLs should be used for a submodule but then throws this work away if the submodule isn't active. Instead perform the activity check earlier and skip inactive submodule in order to avoid doing unnecessary work. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

submodule status: use submodule--helper is-active

2017-03-17T18:06:09Z

Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano