Jeff King <peff@peff.net> writes:
> We can't do this perfectly, because older versions of git do not yet
> know about the option, and will therefore just silently ignore it. And
> for consistency there, we usually do the same for features that we know
> about but are unsupported.

Jep that's why I originally did it this way. But if I (the user) just
have to check the git version to know I'm fine (and not also check which
version of curl it is linked with) to be sure I'd assume that's an
improvement still.

> But I agree for something with security implications like this, we are
> better off warning when we know support is not built in. That's not
> perfect, but it's better than nothing.

I'll add an updated patch taking this into account

> I wonder if there are other options which should get the same treatment.
> Most of the obvious ones I could think of (e.g., http.sslverify) do not
> need it, because either they always have support built, or they
> fail-closed, or both.

does CURLOPT_CAPATH add to CURLOPT_CAINFO or replace it? The
documentation [0] is inconclusive to me in this regard.

  Christoph

[0] https://curl.haxx.se/libcurl/c/CURLOPT_CAPATH.html