All of lore.kernel.org
 help / color / mirror / Atom feed
From: <rsbecker@nexbridge.com>
To: "'Dragan Simic'" <dsimic@manjaro.org>,
	"'Randall Becker'" <randall.becker@nexbridge.ca>
Cc: "'Johannes Schindelin'" <Johannes.Schindelin@gmx.de>,
	"'Randall S. Becker'" <the.n.e.key@gmail.com>,
	<git@vger.kernel.org>
Subject: RE: [PATCH v2 1/2] Teach git version --build-options about libcurl
Date: Mon, 24 Jun 2024 17:15:27 -0400	[thread overview]
Message-ID: <036d01dac67b$a6457da0$f2d078e0$@nexbridge.com> (raw)
In-Reply-To: <5dc18b418f57cb8376b9fd9a5a4ad9d7@manjaro.org>

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.
--Randall


  reply	other threads:[~2024-06-24 21:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-21 18:09 [PATCH v2 0/2] Teach git version --build-options about zlib+libcurl Randall S. Becker
2024-06-21 18:09 ` [PATCH v2 1/2] Teach git version --build-options about libcurl Randall S. Becker
2024-06-24 14:13   ` Johannes Schindelin
2024-06-24 14:33     ` Randall Becker
2024-06-24 17:08       ` Dragan Simic
2024-06-24 21:15         ` rsbecker [this message]
2024-06-24 21:52           ` Dragan Simic
2024-06-24 21:56             ` Randall Becker
2024-07-24 10:51       ` Johannes Schindelin
2024-06-24 15:29     ` Jeff King
2024-06-24 16:06     ` Junio C Hamano
2024-06-24 23:55       ` Jeff King
2024-06-25  0:00         ` Junio C Hamano
2024-07-24 10:48         ` Johannes Schindelin
2024-07-24 20:55           ` Jeff King
2024-07-24 22:17             ` Johannes Schindelin
2024-07-25  6:52               ` Jeff King
2024-07-25 15:28                 ` Junio C Hamano
2024-07-26  0:41                   ` Jeff King
2024-06-21 18:09 ` [PATCH v2 2/2] Teach git version --build-options about zlib versions Randall S. Becker
2024-06-24 14:15   ` Johannes Schindelin
2024-06-24 14:38     ` Randall Becker
2024-07-24 11:02       ` Johannes Schindelin
2024-07-24 13:36         ` Randall Becker
2024-07-24 16:21           ` Junio C Hamano
2024-07-24 16:33             ` rsbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='036d01dac67b$a6457da0$f2d078e0$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=dsimic@manjaro.org \
    --cc=git@vger.kernel.org \
    --cc=randall.becker@nexbridge.ca \
    --cc=the.n.e.key@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.