Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 18, 2018, 01:53 UTC
Message-ID: <xmqq1s8oxbpc.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.1810161225310.4546@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 11 quoted lines

>> In any case, you can use "http.<url>.$variable" to say "I want the
>> http.$variable to be in effect but only when I am talking to <url>".
>> Does it make sense for this new variable, too?  That is, does it
>> benefit the users to be able to do something like this?
>> 
>>     [http] schannelCheckRevoke = no
>>     [http "https://microsoft.com/"] schannelCheckRevoke = yes
>> 
>> I am guessing that the answer is yes.
>
> Frankly, I do not know.  Does it hurt, though?

I did not and I do not think it would. I was wondering if the ability to be able to specify these per destination is something very useful and deserves to be called out in the doc, together with ...

>> I guess the same comment applies to the previous step, but I suspect
>> that the code structure may not allow us to switch the SSL backend
>> so late in the game (e.g. "when talking to microsoft, use schannel,
>> but when talking to github, use openssl").

... this bit.

Show 7 quoted lines

> Crucially, this fails. The short version is: this is good! Because it
> means that Git used the OpenSSL backend, as clearly intended.
>
> <skip if="uninterested in the details">
> Why does it fail?
> ...
> </skip>

So there may still be some polishing needed, but as long as people are not using the "per destination" thing, the code is already good? That is something we may want to document.

Thanks.