Thread (1 message) 1 message, 1 author, 2020-04-07

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

From: Junio C Hamano <hidden>
Date: 2020-04-07 15:24:11

Emily Shaffer [off-list ref] writes:
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help