Re: [PATCH v2 4/6] imap-send: make --curl no-optional

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> 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" -> ???

> we don't need to keep supporting "--no-curl" to bypass the curl
> codepath for the non-tunnel mode.

We do not need to because...?

> @@ -1519,12 +1519,8 @@ int cmd_main(int argc, const char **argv)
>  	if (argc)
>  		usage_with_options(imap_send_usage, imap_send_options);
>  
> -#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 think I made the same comment in some other thread, but the
principle is the same.  If there is no other choice the user can
take, do we force users to stop and be explicit to choose that only
available choice, or do we let the program choose the only available
option for the user while clearly telling the user that is what we
did?  Here, changing the behaviour sounds like a disservice to the
users.