Re: [PATCH v5 2/2] submodule: pass on http.extraheader config settings

[Stefan Beller <sbeller@google.com>]

On Thu, Apr 28, 2016 at 12:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> It's definitely sufficient, it's just annoying if a user shows up every
>> week and says "I want X.Y", and then somebody else shows up a week later
>> and says "I want X.Z".
>>
>> Are we serving any purpose in vetting each one (and if so, what)?
>
> Personally I do not think we would need to filter _anything_ if we
> can tell that the user directly said
>
>         git -c var1=val1 -c var2=val2 $cmd ...
>
> and "git $cmd" ended up needing to spawn another "git" subcommand,
> possibly in some other repository (i.e. "$cmd" in this case is
> likely to be "submodule", but in principle it does not have to be).
> If the user somehow gives variables like core.worktree that are
> inappropriate to be applied across repositories, that's user's
> problem, i.e. "don't do it then if it hurts".

So when going with that philosophy, the user might be missing
switches like

    -c-for-this-repo-only core.worktree=... -c
submodule.worktree=align-relative-to-parent

i.e. when shifting the responsibility to the user, we need to have
switches to pass options to the repository or a subset of submodules?

>
> If we are doing any filtering, however, it is always hard, if not
> impossible, to take away what we originally granted, even by
> mistake, for any reason, even for correctness or for security, in a
> later release.
>
> We probably could sidestep it by introducing an end-user
> configurable "whitelist" somewhere.
>
>