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?
