Thread (222 messages) 222 messages, 11 authors, 2020-04-06

Re: [PATCH] bugreport: add tool to generate debugging info

From: Emily Shaffer <hidden>
Date: 2019-08-15 22:24:35

On Thu, Aug 15, 2019 at 10:07:57PM +0200, Johannes Schindelin wrote:
Hi,

On Thu, 15 Aug 2019, Derrick Stolee wrote:
quoted
On 8/14/2019 10:34 PM, Emily Shaffer wrote:
quoted
diff --git a/git-bugreport.sh b/git-bugreport.sh
new file mode 100755
index 0000000000..2200703a51
--- /dev/null
+++ b/git-bugreport.sh
At first I was alarmed by "What? another shell script?" but this
command should prioritize flexibility and extensibility over speed.
Running multiple processes shouldn't be too taxing for what we are
trying to do here.
Git for Windows sometimes receives bug reports about Bash not being able
to start (usually it is a DLL base address problem, related to the way
Cygwin and MSYS2 emulate `fork()`).
Hmm. In a case like this, then, how is someone using GfW at all?
Embarrassingly, I don't actually have a way to try it out for myself.
It seems there's no GUI, and users are using it through the command line
in mingw, so when you say "bash doesn't start" do you mean "users can't
use the mingw prompt at all"?
In such a case, `git bugreport` would only be able to offer a reason for
yet another bug report instead of adding useful metadata.

Something to keep in mind when deciding how to implement this command.

Ciao,
Dscho
Yeah, that's an interesting point, thanks for bringing it up. So, in the
case when bash won't start at all, what does that failure look like? How
much of Git can users still use? For example, would they be able to get
far enough to run a binary git-bugreport?

 - Emily
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help