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

[Jeff King <peff@peff.net>]

On Thu, Jul 25, 2024 at 12:17:08AM +0200, Johannes Schindelin wrote:

> All true, but the name `git version` also sets some expectations. Users
> who run `<command> version` will expect to see the version of the command
> they are actually using currently.
> 
> For example, `curl -V` will list something like:
> 
> 	curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2
> 	zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0
> 	(+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0
> 	librtmp/2.3 OpenLDAP/2.5.18
> 
> Those are the versions of the components that are actually used when
> invoking `curl` commands, not versions that were present on the machine
> that built the `curl` package.
> 
> Compare that to what we're experiencing with Git for Windows v2.46.0-rc2:
> `git version --build-options` lists `libcurl: 8.8.0`. But running `git
> fetch` will actually use libcurl v8.9.0, not v8.8.0. And the output does
> not mention that this is the compile-time version. It lists only one
> version, as if it was the one that the Git executable were using.

Well, yes. The whole point of farming it out to remote-curl was so that
we could show that run-time version, which was what I said in the
message you were responding to. So I think we agree.

I would be fine showing _both_ the run-time and compile-time versions,
if they are clearly marked.

> > So whether that is in the form of "git bugreport --dump", or if all of
> > the collection is moved to "git version --build-info" and then bugreport
> > uses that to fill out its template, I don't care.
> 
> I feel that we may need a different command for that than `bugreport
> --dump`, something that reflects that the user wants to gather data to
> investigate an issue, but not necessarily report a bug to the Git project,
> and that we should guide users to use that command instead of `git
> version` when investigating such issues.
> 
> A command with a name along the lines of `git diagnose`, I'd say.

OK. I don't really care much either way how it is spelled, though my
inclination is that we already have a confusing number of commands and
should avoid adding more.

But my main point was that we have two ways of collecting data now, and
it would be easier for users if they were unified, however the result is
invoked.

-Peff