Re: [PATCH] http.proxy: also mention https_proxy and all_proxy

Clemens Buchacher [off-list ref] writes:

On Sat, Mar 03, 2012 at 02:22:39PM -0800, Junio C Hamano wrote:

quoted

As to the way forward, I suspect that http.proxy was a mistake to begin
with, considering the structure of namespace our configuration variables
fit in.  Shouldn't they be proxy.http, proxy.https, etc.?

I actually prefer the current behavior, which is to configure only one
proxy for all protocols. I have not seen a setup where HTTP and HTTPS
are routed through different proxies before. But if this is really
needed, one has the option to use the environment variable, or
remote.<name>.proxy.

I suggest instead that we map curl's CURLOPT_PROXY to core.proxy.  That
would also fit well with the remote.<name>.proxy scheme.

Contaminating core.* namespace would not solve anything.

People are already relying on http.proxy to apply to any cURL transport,
so we will keep supporting it anyway.  There is no justification to teach
new people to learn that both exists, and the transport is not core anyway; 
it is still cURL specific.

I forgot about remote.<name>.proxy that already can let you use different
proxies for http/https, and the use of different ones per protocol would
be rare to begin with, so I agree that we would not have to worry about
introducing proxy.{http,https,...}.

Thanks.