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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 24, 2024, 22:17 UTC
Message-ID: <8ef819f0-e80a-74ec-274d-fe10991fe992@gmx.de>
In-Reply-To: <20240724205541.GA557365@coredump.intra.peff.net>

Hi Jeff,

On Wed, 24 Jul 2024, Jeff King wrote:

Show 18 quoted lines

> On Wed, Jul 24, 2024 at 12:48:20PM +0200, Johannes Schindelin wrote:
>
> > > But we could also have "git version --build-options" call "remote-https
> > > --build-options" automatically, and just let it dump to the shared
> > > stdout stream.
> >
> > Teaching `git version` to show the cURL version may not be the best idea,
> > especially when it comes to the version used at runtime and using the
> > command-line option `--build-options` (with the option being specifically
> > about the build, not the runtime, version that was used).
> >
> > Wouldn't it be better to go with Emily's approach to surface this
> > information via `git bugreport` instead of `git version`, potentially
> > enhanced to show both build-time and runtime version of libcurl?
>
> I don't have a strong preference either way. I naturally turned towards
> "git version" because that's what this thread was about, and also
> because it predates git-bugreport.

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.

I suspect that this behavior will confuse users, and that this kind of user experience will come back to haunt the Git project.

Show 10 quoted lines

> It feels like there may be some duplication / overlap between what those
> two things inspect, and we should perhaps unify them. One thing I
> notice about bugreport is that it doesn't have a way to just dump
> information without trying to start a bugreport. I'd be very unlikely to
> use it myself for reporting a bug, but I may want to dump information
> about git while debugging.
>
> 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.

Ciao, Johannes