Hi Jeff, On Wed, 24 Jul 2024, Jeff King wrote: > 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. > 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
