Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> On Thu, Feb 02 2023, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>>
>>> In the preceding commit the old "USE_CURL_FOR_IMAP_SEND" define became
>>> always true, as we now require libcurl for git-imap-send.
>>>
>>> But as we require OpenSSL for the "tunnel" mode we still need to keep
>>> the OpenSSL codepath around (ee [1] for an attempt to remove it). But
>>
>> "(ee" -> ???
>
> Should be "e.g.", will fix.
I think it's more like a missing 'S' before 'ee'.
>>> -#if defined(NO_OPENSSL)
>>> - if (!use_curl) {
>>> - warning("--no-curl not supported in this build");
>>> - use_curl = 1;
>>> - }
>>> -#endif
>>> + if (!use_curl)
>>> + die(_("the --no-curl option to imap-send has been deprecated"));
>>
>> We used to force use of cURL when there is no other way to make the
>> program work (i.e. there is no direct OpenSSL codepath available),
>> instead of refusing to work (and forcing user to say --curl or to
>> stop saying --no-curl, which is one unnecessary roadblock for the
>> user). Why do we want to change the error handling strategy that
>> has been in place?
>
> I can change this to a soft error, but it seemed more sensible to rip
> the band-aid off an option that's never going to do anything now,
> whereas before it would do something based on how you compiled git.
Stopping and forcing the user to spend an extra step does not sound
sensible to me. Let's never do this kind of behaviour change "while
at it".
Thanks.
