From: Emily Shaffer <emilyshaffer@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v12 3/5] bugreport: gather git version and build info
Date: Tue, 7 Apr 2020 11:42:40 -0700 [thread overview]
Message-ID: <20200407184240.GB137962@google.com> (raw)
In-Reply-To: <xmqqeet0urts.fsf@gitster.c.googlers.com>
On Mon, Apr 06, 2020 at 04:17:51PM -0700, Junio C Hamano wrote:
> Emily Shaffer <emilyshaffer@google.com> writes:
>
> > It's not ideal to directly call 'git version --build-options' because
> > that output goes to stdout. Instead, wrap the version string in a helper
> > within help.[ch] library, and call that helper from within the bugreport
> > library.
>
> This means that "git-bugreport" that can be a different binary from
> say "git-remote-curl" (or "git-version" for that matter) would still
> report whatever version string that was compiled into "bugreport".
>
> Reporting the version of "bugreport" is *not* useless, and what this
> step adds to the report is good.
>
> But the version number of "bugreport" may not have much to do with
> the binary the end user is having trouble with, so we'd also want
> the version of the main part of "git", and other standalone "git"
> subprograms like "git-remote-curl", reported separately, probably
> together with $PATH, $GIT_EXEC_PATH and what appears in the
> directories listed on these environment variables.
>
> If "git version --build-options" writes to its standard output
> stream, that is a good thing, as it makes it easy to spawn and read
> what it says via the run_command() API, and there is one less thing
> to worry about (it would be a bit more cumbersome if the output goes
> to the standard error stream).
>
> As "git-remote-curl" would also be a separate binary, we'd have to
> use the same technique to report version number (and perhaps curl's
> library version and its configuration?), perhaps by teaching the
> subcommand a new option to dump such details to its standard output.
>
> Using the same technique to report the version about the "git"
> itself would be consistent thing to do, as a preparation for future
> steps that reports the details about "git-remote-curl".
Sure. I will include a run_command() call to "git version
--build-options" (or is it --build-info?) in the same series where I
re-introduce the call to "git-remote-curl", since they will look pretty
similar; around that time I will clean up what "git-bugreport" reports
about its own version/build info, too.
To be clear, do you want me to include the output of get_compiler_info()
in "git version --build-options" when I do that change, too?
- Emily
next prev parent reply other threads:[~2020-04-07 18:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 21:43 [PATCH v10 0/5] add git-bugreport tool Emily Shaffer
2020-03-23 21:43 ` [PATCH v10 1/5] help: move list_config_help to builtin/help Emily Shaffer
2020-03-23 21:43 ` [PATCH v10 2/5] bugreport: add tool to generate debugging info Emily Shaffer
2020-03-23 21:43 ` [PATCH v10 3/5] bugreport: gather git version and build info Emily Shaffer
2020-03-23 21:43 ` [PATCH v10 4/5] bugreport: add uname info Emily Shaffer
2020-03-23 21:43 ` [PATCH v10 5/5] bugreport: add compiler info Emily Shaffer
2020-03-23 23:10 ` Junio C Hamano
2020-03-25 21:10 ` Emily Shaffer
2020-03-25 21:24 ` [PATCH v11 0/5] add git-bugreport tool Emily Shaffer
2020-03-25 21:24 ` [PATCH v11 1/5] help: move list_config_help to builtin/help Emily Shaffer
2020-03-25 21:24 ` [PATCH v11 2/5] bugreport: add tool to generate debugging info Emily Shaffer
2020-04-01 20:17 ` SZEDER Gábor
2020-03-25 21:24 ` [PATCH v11 3/5] bugreport: gather git version and build info Emily Shaffer
2020-03-25 21:24 ` [PATCH v11 4/5] bugreport: add uname info Emily Shaffer
2020-03-25 21:25 ` [PATCH v11 5/5] bugreport: add compiler info Emily Shaffer
2020-04-06 22:45 ` [PATCH v12 0/5] bugreport: add tool to generate debugging info Emily Shaffer
2020-04-06 22:45 ` [PATCH v12 1/5] help: move list_config_help to builtin/help Emily Shaffer
2020-04-06 23:04 ` Junio C Hamano
2020-04-06 22:45 ` [PATCH v12 2/5] bugreport: add tool to generate debugging info Emily Shaffer
2020-04-06 22:45 ` [PATCH v12 3/5] bugreport: gather git version and build info Emily Shaffer
2020-04-06 23:17 ` Junio C Hamano
2020-04-07 18:42 ` Emily Shaffer [this message]
2020-04-07 20:05 ` Junio C Hamano
2020-04-07 20:34 ` Emily Shaffer
2020-04-06 22:45 ` [PATCH v12 4/5] bugreport: add uname info Emily Shaffer
2020-04-06 23:20 ` Junio C Hamano
2020-04-06 22:45 ` [PATCH v12 5/5] bugreport: add compiler info Emily Shaffer
2020-04-06 23:31 ` Junio C Hamano
2020-04-06 23:47 ` Danh Doan
2020-04-07 15:09 ` Junio C Hamano
2020-04-07 18:35 ` Emily Shaffer
2020-04-07 15:24 ` [PATCH v12 0/5] bugreport: add tool to generate debugging info Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200407184240.GB137962@google.com \
--to=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).