Re: [PATCH] submodule: stop sanitizing config options
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 4, 2016, 18:43 UTC
- Message-ID
- <xmqqzis5hdek.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20160504080047.GA2436@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 15 quoted lines
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3a40d4b..c9d53e1 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -197,9 +197,9 @@ isnumber()
> # of the settings from GIT_CONFIG_PARAMETERS.
> sanitize_submodule_env()
> {
> - sanitized_config=$(git submodule--helper sanitize-config)
> + save_config=$GIT_CONFIG_PARAMETERS
> clear_local_git_env
> - GIT_CONFIG_PARAMETERS=$sanitized_config
> + GIT_CONFIG_PARAMETERS=$save_config
> export GIT_CONFIG_PARAMETERS
> }This does "clear the obviously per-repository stuff, but add back in anything that came from -c". If it is easy to do "add anything that came from -c, and then clear the obviously per-repository stuff", we don't even have to say "exporting core.worktree down may hurt; do not do it then", which may be the best of both worlds?
Or have we decided that even sharing core.worktree may have a valid use case and it is better not to filter them?