]> git.ipfire.org Git - thirdparty/git.git/commit - git-submodule.sh
submodule: stop sanitizing config options
authorJeff King <peff@peff.net>
Thu, 5 May 2016 01:22:19 +0000 (21:22 -0400)
committerJunio C Hamano <gitster@pobox.com>
Fri, 6 May 2016 19:54:27 +0000 (12:54 -0700)
commit89044baa8b8a14b48e78a42ebdc43cfcd144ce28
tree007d5ef2fc99a223bf9245a3f78b062bc68d9930
parentc12e8656700be6084aec49df66447e701fda1ecf
submodule: stop sanitizing config options

The point of having a whitelist of command-line config
options to pass to submodules was two-fold:

  1. It prevented obvious nonsense like using core.worktree
     for multiple repos.

  2. It could prevent surprise when the user did not mean
     for the options to leak to the submodules (e.g.,
     http.sslverify=false).

For case 1, the answer is mostly "if it hurts, don't do
that". For case 2, we can note that any such example has a
matching inverted surprise (e.g., a user who meant
http.sslverify=true to apply everywhere, but it didn't).

So this whitelist is probably not giving us any benefit, and
is already creating a hassle as people propose things to put
on it. Let's just drop it entirely.

Note that we still need to keep a special code path for
"prepare the submodule environment", because we still have
to take care to pass through $GIT_CONFIG_PARAMETERS (and
block the rest of the repo-specific environment variables).

We can do this easily from within the submodule shell
script, which lets us drop the submodule--helper option
entirely (and it's OK to do so because as a "--" program, it
is entirely a private implementation detail).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/submodule--helper.c
git-submodule.sh
submodule.c
submodule.h
t/t7412-submodule--helper.sh [deleted file]