Re: [PATCH v12 0/5] bugreport: add tool to generate debugging info

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 7, 2020, 15:24 UTC
Message-ID: <xmqqlfn7tj3d.fsf@gitster.c.googlers.com>
In-Reply-To: <20200406224526.256074-1-emilyshaffer@google.com>

Emily Shaffer <emilyshaffer@google.com> writes:

Show 9 quoted lines

> Since v11, reordered tests per SZEDER's comment so that the
> test_when_finished lines come first in each test.
>
> Emily Shaffer (5):
>   help: move list_config_help to builtin/help
>   bugreport: add tool to generate debugging info
>   bugreport: gather git version and build info
>   bugreport: add uname info
>   bugreport: add compiler info

Overall it was a pleasnt read.

Just to avoid misunderstanding, those comments in which I envisioned a way to report versions and attributes on different parts of "git" (and I expect we'd be reporting versions and add-ons to tools like 'wish' that runs gitk and git-gui, 'perl' and 'python' in a similar way---by finding them on the $PATH and asking them who they are) are NOT "without these, the bugreport tool would not be useful", but "we will in time need these, so let's keep them in mind" issues [*1*].

So, I am hoping that this is ready to move to 'next'.

Thanks.

[Footnote]

*1* What we saw here in the review showed us a very good starting point to report the version of the source one binary was built from, and the compiler and library that binary was built with, and various attributes of the system that is running that binary. Thanks to step [1/5], these helper functions can also be linked to help other parts of "git" (like the transport) report the first two (some code may further need to be moved so that they can be called from the built-ins and standalones). The system that the binary is running on would be the same anyway, so there is no need to duplicate that part of the report.