git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Emily Shaffer <emilyshaffer@google.com>,
	git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH v3 0/9] add git-bugreport tool
Date: Tue, 29 Oct 2019 12:13:27 +0100 (CET)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1910291202160.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqqd0eg8geu.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Tue, 29 Oct 2019, Junio C Hamano wrote:

> Emily Shaffer <emilyshaffer@google.com> writes:
>
> > Thanks for the patience with the long wait, all. Here's an attempt at
> > the rewrite in C; I think it does verbatim what the sh version did
> > except that this doesn't print the reflog - Jonathan Nieder was good
> > enough to point out to me that folks probably don't want to share their
> > commit subjects all willy-nilly if they're working on something
> > secretive.
>
> Is the goal to give a tool the end users can type "git
> bugreport<RET>" and automatically send the result to this mailing
> list (or some bug tracker)?  Or is this only about producing a
> pre-filled bug report template to be slurped into their MUA and then
> further manually edited before sending it out?
>
> It probably is controversial if we exposed contents of hooks scripts
> (I can imagine some people may trigger external process by pinging a
> URL that includes credential material out of laziness), so the
> presence test you have is probably a good stopping point.  I do not
> know how much it helps to know which hooks exist in order to
> diagnose an anomaly without knowing what their contents are, but it
> is a start.
>
> By the way, I doubt that it is the best use of developer time to
> write these in C---taking various pieces of information from
> different places to prepare a text file sounds more suited to
> scripting languages, especially while we are still learning what
> kind of information we want to collect and how we want to present
> the final result (iow, for the first handful of years after
> deploying this command).

If you want to limit Git to Linux, then relying on a specific scripting
language like Unix shell scripting sounds okay.

If you target more platforms, then a range of scripting languages sounds
a lot more sensible, my top choice would be node.js.

I understand that that is not an option here, and there is a strong
preference for Unix shell scripting in Git. This is a bit unfortunate:

A good chunk of the bug reports I see in Git for Windows are _about_
problems with Unix shell scripting. There are fork problems, problems
where `add_item` failed (which is one of the least helpful error
messages I saw in my entire life), there are problems with anti-malware
causing segmentation faults in the Unix shell script interpreter (the
MSYS2 Bash), and there are even (believe it or not) problems with
_display drivers_. Yes, that is right, display drivers can interfere
with Unix shell script execution on Windows. (This is really rare, but
hey, bug reports are rare in Git for Windows to begin with...)

All of these problems _prevent_ Unix shell scripts from being
interpreted as expected on Windows. Which would ridicule the idea of
reporting any of these bugs using a tool that is implemented in Unix
shell.

And what is worse than a bug in an application? A bug in the
application's very own bug reporting tool.

I pointed this out to Emily, and that is the reason why this amount of
work was put in to _improve_ the tool, precisely by _not_ implementing
it as a Unix shell script, but instead in plain C (which is a _lot_ more
robust).

Ciao,
Dscho

      reply	other threads:[~2019-10-29 11:13 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15  2:34 [PATCH] bugreport: add tool to generate debugging info Emily Shaffer
2019-08-15 14:15 ` Derrick Stolee
2019-08-15 14:36   ` Junio C Hamano
2019-08-15 22:52     ` Emily Shaffer
2019-08-15 23:40       ` Junio C Hamano
2019-08-16  1:25         ` Emily Shaffer
2019-08-16 16:41           ` Junio C Hamano
2019-08-16 19:08             ` Emily Shaffer
2019-08-15 20:07   ` Johannes Schindelin
2019-08-15 22:24     ` Emily Shaffer
2019-08-16 20:19       ` Johannes Schindelin
2019-08-15 20:13   ` Emily Shaffer
2019-08-15 18:10 ` Junio C Hamano
2019-08-15 21:52   ` Emily Shaffer
2019-08-15 22:29     ` Junio C Hamano
2019-08-15 22:54       ` Emily Shaffer
2019-08-17  0:39 ` [PATCH v2 0/2] add git-bugreport tool Emily Shaffer
2019-08-17  0:39   ` [PATCH v2 1/2] bugreport: add tool to generate debugging info Emily Shaffer
2019-08-17  0:39   ` [PATCH v2 2/2] bugreport: generate config whitelist based on docs Emily Shaffer
2019-08-17 20:38     ` Martin Ågren
2019-08-21 17:40       ` Emily Shaffer
2019-10-25  2:51   ` [PATCH v3 0/9] add git-bugreport tool Emily Shaffer
2019-10-25  2:51     ` [PATCH v3 1/9] bugreport: add tool to generate debugging info Emily Shaffer
2019-10-29 20:29       ` Josh Steadmon
2019-11-16  3:11       ` Junio C Hamano
2019-11-19 20:25         ` Emily Shaffer
2019-11-19 23:24           ` Johannes Schindelin
2019-11-20  0:37             ` Junio C Hamano
2019-11-20 10:51               ` Johannes Schindelin
2019-11-19 23:31           ` Johannes Schindelin
2019-11-20  0:39             ` Junio C Hamano
2019-11-20  2:09             ` Emily Shaffer
2019-11-20  0:32           ` Junio C Hamano
2019-10-25  2:51     ` [PATCH v3 2/9] bugreport: generate config whitelist based on docs Emily Shaffer
2019-10-28 13:27       ` Johannes Schindelin
2019-10-25  2:51     ` [PATCH v3 3/9] bugreport: add version and system information Emily Shaffer
2019-10-28 13:49       ` Johannes Schindelin
2019-11-08 21:48         ` Emily Shaffer
2019-11-11 13:48           ` Johannes Schindelin
2019-11-14 21:42             ` Emily Shaffer
2019-10-29 20:43       ` Josh Steadmon
2019-10-25  2:51     ` [PATCH v3 4/9] bugreport: add config values from whitelist Emily Shaffer
2019-10-28 14:14       ` Johannes Schindelin
2019-12-11 20:48         ` Emily Shaffer
2019-12-15 17:30           ` Johannes Schindelin
2019-10-29 20:58       ` Josh Steadmon
2019-10-30  1:37         ` Junio C Hamano
2019-11-14 21:55           ` Emily Shaffer
2019-10-25  2:51     ` [PATCH v3 5/9] bugreport: collect list of populated hooks Emily Shaffer
2019-10-28 14:31       ` Johannes Schindelin
2019-12-11 20:51         ` Emily Shaffer
2019-12-15 17:40           ` Johannes Schindelin
2019-10-25  2:51     ` [PATCH v3 6/9] bugreport: count loose objects Emily Shaffer
2019-10-28 15:07       ` Johannes Schindelin
2019-12-10 22:34         ` Emily Shaffer
2019-10-29 21:18       ` Josh Steadmon
2019-10-25  2:51     ` [PATCH v3 7/9] bugreport: add packed object summary Emily Shaffer
2019-10-28 15:43       ` Johannes Schindelin
2019-12-11  0:29         ` Emily Shaffer
2019-12-11 13:37           ` Johannes Schindelin
2019-12-11 20:52             ` Emily Shaffer
2019-10-25  2:51     ` [PATCH v3 8/9] bugreport: list contents of $OBJDIR/info Emily Shaffer
2019-10-28 15:51       ` Johannes Schindelin
2019-10-25  2:51     ` [PATCH v3 9/9] bugreport: print contents of alternates file Emily Shaffer
2019-10-28 15:57       ` Johannes Schindelin
2019-11-19 20:40         ` Emily Shaffer
2019-10-29  1:54     ` [PATCH v3 0/9] add git-bugreport tool Junio C Hamano
2019-10-29 11:13       ` Johannes Schindelin [this message]

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=nycvar.QRO.7.76.6.1910291202160.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=stolee@gmail.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).