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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2024, 16:06 UTC
Message-ID: <xmqqed8me36c.fsf@gitster.g>
In-Reply-To: <f44f1e25-41ca-0784-3186-f9e1bdae0d4f@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

>> +#if defined LIBCURL_VERSION
>> +		strbuf_addf(buf, "libcurl: %s\n", LIBCURL_VERSION);
>
> 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.

An unstated question is that we are not reporting the version of openssl we happened to find at runtime, and if it is better to report it, not the version Git was compiled to work with?

I obviously do not care about runtime performance of "git version --build-options", but I am not enthused by the idea of forcing dynamic-linking with libcURL and all of its dependencies when a script runs a simple "git rev-parse HEAD".

        $ ldd git | wc -l
        6
        $ ldd git-remote-http | wc -l
        34

> Wouldn't calling `curl_version()` make more sense here?

I wouldn't give that question an outright "no", but unless "git version" is split out of the builtin suite of commands and made into a standalone binary, I would *not* be able to give an unconditional "yes".

For now, let's stop at the simplest solution---if the library project gives us a CPP macro to use for _this exact purpose_, let's take the offer.