Re: [PATCH v5 2/2] submodule: pass on http.extraheader config settings
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 28, 2016, 19:28 UTC
- Message-ID
- <xmqqwpnh4joq.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20160428191038.GA10574@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 5 quoted lines
> 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".
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.