Clemens Buchacher <drizzd@xxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html