On Thu, Aug 15, 2019 at 10:07:57PM +0200, Johannes Schindelin wrote: > Hi, > > On Thu, 15 Aug 2019, Derrick Stolee wrote: > > > On 8/14/2019 10:34 PM, Emily Shaffer wrote: > > > 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
