On Monday, June 24, 2024 5:53 PM, Dragan Simic wrote: >On 2024-06-24 23:15, rsbecker@xxxxxxxxxxxxx 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? I think that's where we've gone, yes.
