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

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

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