Re: [PATCH v2 1/2] Teach git version --build-options about libcurl

[Dragan Simic <dsimic@manjaro.org>]

On 2024-06-24 23:15, rsbecker@nexbridge.com wrote:
> On Monday, June 24, 2024 1:09 PM, Dragan Simic wrote:
>> On 2024-06-24 16:33, Randall Becker wrote:
>>> On Monday, June 24, 2024 10:13 AM, Johannes Schindelin wrote:
>>>> I am not sure that this is the most helpful information Git can
>>>> provide:
>>>> It reports the version against which Git was _compiled_, whereas the
>>>> version it is _running against_ might be quite different.
>>>> 
>>>> Wouldn't calling `curl_version()` make more sense here?
>>> 
>>> I think the more important information is the build used. My 
>>> reasoning
>>> is that one can call run curl --version to see the current curl
>>> install. However, different versions of curl have potential API
>>> changes - same argument with OpenSSL. What initiated this for me (the
>>> use case) started with a customer who incorrectly installed a git
>>> build for OpenSSL 3.2 (and its libcurl friend). Git would then get a
>>> compatibility issue when attempting to use either library. The
>>> customer did not know (!) they had the git for OpenSSL 3.2 version 
>>> and
>>> I had no way to determine which one they had without seeing their 
>>> path
>>> - hard in an email support situation. Having git version
>>> --build-options report what was used for the build *at a 
>>> compatibility
>>> level* would have easily shown that the available library (after
>>> running openssl version or curl --version) reported different values.
>>> Otherwise, we are back to guessing what they installed. The goal is 
>>> to
>>> compare what git expects with what git has available. The above 
>>> series
>>> makes this comparative information available.
>> 
>> How about announcing both versions of the library if they differ, and 
>> only
> one
>> version if they're the same?  We're building this to serve as a way 
>> for
> debugging
>> various issues, having that information available could only be 
>> helpful.
> 
> I don't have a huge problem with that except it will significantly 
> decrease
> performance. We do not currently have to load libcurl/openssl to obtain 
> the
> build version (it is the --build-options flag), so adding additional 
> load on
> this command is not really what the series is about. Doing this 
> run-time
> check might be something someone else may want to take on separately, 
> but
> from a support use-case standpoint, it should be covered as is. Doing a
> comparison is a separate use case.

Yes, the additional load is actually a bit concerning.  Perhaps we could
wrap the current series up as-is and leave the possible improvements to
the follow-up patches?