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

Merge branch 'sb/submodule-update-initial-runs-custom-script'

2017-02-03T19:25:19Z

The user can specify a custom update method that is run when "submodule update" updates an already checked out submodule. This was ignored when checking the submodule out for the first time and we instead always just checked out the commit that is bound to the path in the superproject's index. * sb/submodule-update-initial-runs-custom-script: submodule update: run custom update script for initial populating as well

Merge branch 'sb/submodule-add-force'

2017-02-02T21:36:54Z

"git submodule add" used to be confused and refused to add a locally created repository; users can now use "--force" option to add them. * sb/submodule-add-force: submodule add: extend force flag to add existing repos

submodule update: run custom update script for initial populating as well

2017-01-26T19:06:07Z

In 1b4735d9f3 (submodule: no [--merge|--rebase] when newly cloned, 2011-02-17), all actions were defaulted to checkout for populating a submodule initially, because merging or rebasing makes no sense in that situation. Other commands however do make sense, such as the custom command that was added later (6cb5728c43, submodule update: allow custom command to update submodule working tree, 2013-07-03). I am unsure about the "none" command, as I can see an initial checkout there as a useful thing. On the other hand going strictly by our own documentation, we should do nothing in case of "none" as well, because the user asked for it. Reported-by: Han-Wen Nienhuys Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Merge branch 'sb/submodule-init'

2017-01-23T23:59:21Z

Error message fix. * sb/submodule-init: submodule update --init: display correct path from submodule

Merge branch 'sb/submodule-embed-gitdir'

2017-01-23T23:59:20Z

Help-text fix. * sb/submodule-embed-gitdir: submodule absorbgitdirs: mention in docstring help

submodule update --init: display correct path from submodule

2017-01-12T22:36:20Z

In the submodule helper we did not correctly handled the display path for initializing submodules when both the submodule is inside a subdirectory as well as the command being invoked from a subdirectory (as viewed from the superproject). This was broken in 3604242f080, which was written at a time where there was no super-prefix available, so we abused the --prefix option for the same purpose and could get only one case right (the call from within a subdirectory, not the submodule being in a subdirectory). Test-provided-by: David Turner Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

submodule absorbgitdirs: mention in docstring help

2017-01-12T22:09:28Z

This part was missing in f6f85861 (submodule: add absorb-git-dir function, 2016-12-12). Noticed-by: Jonathan Nieder Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Merge branch 'sb/submodule-embed-gitdir'

2017-01-10T23:24:28Z

A new submodule helper "git submodule embedgitdirs" to make it easier to move embedded .git/ directory for submodules in a superproject to .git/modules/ (and point the latter with the former that is turned into a "gitdir:" file) has been added. * sb/submodule-embed-gitdir: worktree: initialize return value for submodule_uses_worktrees submodule: add absorb-git-dir function move connect_work_tree_and_git_dir to dir.h worktree: check if a submodule uses worktrees test-lib-functions.sh: teach test_commit -C submodule helper: support super prefix submodule: use absolute path for computing relative path connecting

Merge branch 'bw/transport-protocol-policy'

2016-12-27T08:11:41Z

Finer-grained control of what protocols are allowed for transports during clone/fetch/push have been enabled via a new configuration mechanism. * bw/transport-protocol-policy: http: respect protocol.*.allow=user for http-alternates transport: add from_user parameter to is_transport_allowed http: create function to get curl allowed protocols transport: add protocol policy config option http: always warn if libcurl version is too old lib-proto-disable: variable name fix

transport: add protocol policy config option

2016-12-15T17:29:13Z

Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to specify a whitelist of protocols to be used in clone/fetch/push commands. This patch introduces new configuration options for more fine-grained control for allowing/disallowing protocols. This also has the added benefit of allowing easier construction of a protocol whitelist on systems where setting an environment variable is non-trivial. Now users can specify a policy to be used for each type of protocol via the 'protocol..allow' config option. A default policy for all unconfigured protocols can be set with the 'protocol.allow' config option. If no user configured default is made git will allow known-safe protocols (http, https, git, ssh, file), disallow known-dangerous protocols (ext), and have a default policy of `user` for all other protocols. The supported policies are `always`, `never`, and `user`. The `user` policy can be used to configure a protocol to be usable when explicitly used by a user, while disallowing it for commands which run clone/fetch/push commands without direct user intervention (e.g. recursive initialization of submodules). Commands which can potentially clone/fetch/push from untrusted repositories without user intervention can export `GIT_PROTOCOL_FROM_USER` with a value of '0' to prevent protocols configured to the `user` policy from being used. Fix remote-ext tests to use the new config to allow the ext protocol to be tested. Based on a patch by Jeff King Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano