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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 4, 2012, 23:07 UTC
Message-ID: <7vhay455is.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120304124627.GA1596@ecki>

Clemens Buchacher <drizzd@aon.at> writes:

Show 14 quoted lines

> On Sat, Mar 03, 2012 at 02:22:39PM -0800, Junio C Hamano wrote:
>> 
>> 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.