git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

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