Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Emily Shaffer <emilyshaffer@google.com>
Cc: Derrick Stolee <stolee@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] bugreport: add tool to generate debugging info
Date: Fri, 16 Aug 2019 22:19:31 +0200 (CEST)
Message-ID: <nycvar.QRO.7.76.6.1908162204380.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20190815222427.GC208753@google.com>

Hi Emily,

On Thu, 15 Aug 2019, Emily Shaffer wrote:

> On Thu, Aug 15, 2019 at 10:07:57PM +0200, Johannes Schindelin wrote:
> >
> > 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?

On Windows, there are native command-line interpreters available that
are _not_ Bash: PowerShell and CMD.

These days, you can get away with using Git _without_ a working Unix
shell most of the time. There are only preciously few commands left that
are still written as scripts, and most of these seem to be used less
often than one might think:

	- submodule
	- bisect
	- filter-branch
	- instaweb
	- mergetool
	- some uncommon merge strategies
	- rebase -p (already deprecated)
	- several CVS/Subversion/Arch/Quilt integrations
	- send-email (only relevant for mailing list centric projects,
	  again, not very common any longer)
	- request-pull (I would not be surprised if this is specific for
	  the Linux project, as if that project was even close to the
	  main user of Git)

So as long as you don't use submodules, and as long as you are unaware
of the `bisect` command, which would comprise the majority of Git users
in my experience, you can totally use Git for Windows without using Bash
or Perl, i.e. without using the Cygwin/MSYS2 runtime that seems to be
one of the common causes for trouble in Git for Windows.

> 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"?

There is no MinGW prompt.

MinGW stands for "Minimal GNU on Windows", but it really refers to a way
to compile native Win32 programs via GCC. Meaning that some of the POSIX
functionality Unix/Linux developers have come to expect is unavailable.
For example, `fork()`. Which means that there is no native port of Bash
to Windows, at least not that _I_ am aware of.

Git for Windows comes with a "Git Bash", which is essentially a Bash
built against the MSYS2 runtime (i.e. it is much more like a Cygwin
executable than like a Win32 executable).

The common way to run Git for Windows is actually via `git.exe`,
independent of what particular command-line interpreter you prefer.

> > 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.
>
> 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?

See above.

If I were you, I would not write `git bugreport` as anything but a
built-in, written in C. Unless there are _really_ good reasons not to
[*1*].  And quite honestly, I don't see any such reasons.

Ciao,
Dscho

Footnote *1*: One good reason to use the MSYS2 Bash would be to be able
to use MSYS2's POSIX emulation layer, e.g. to talk to the SSH agent
(that is also an MSYS2 program, meaning that it communicates via
emulated Unix sockets, which is a facility not available to native Win32
programs).

Another valid reason to use the MSYS2 Bash is to be able to talk to the
(emulated) pseudo TTYs provided by the MSYS2 runtime, e.g. when running
inside a MinTTY window, which is the default for Git Bash in Git for
Windows.

  reply index

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15  2:34 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 [this message]
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-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
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

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

* 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.1908162204380.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git