Re: [PATCH v9 2/5] bugreport: add tool to generate debugging info

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 9, 2020, 19:17 UTC
Message-ID: <nycvar.QRO.7.76.6.2003092013090.46@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqr1y11sn7.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Mon, 9 Mar 2020, Junio C Hamano wrote:

Show 14 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 6 Mar 2020, Junio C Hamano wrote:
> >
> >> What makes it possible by making "git bugreport" stand-alone is for
> >> it to link with libraries that the remainder of Git, including the
> >> transports that link with libcurl, has no business linking with (a
> >> library to obtain system details for diagnostic purposes, for
> >> example).
> >
> > That would, however, make `git-bugreport` more fragile than `git`, i.e.
> > the former might fail to launch under more circumstances than the latter.
>
> That's a bug.  You can go fix it when it happens.

Heh... yeah, that would be a bug, and the user would not be able to report it via `git bugreport`...

Which is the whole point of my complaint.

Isn't it obvious that we should not have an independent `git-bugreport` by now? With a stand-alone `git-bugreport`, we might

- fail to load the .so files under more circumstances than `git` would
  (since we link to `libgit.a`, we cannot have a subset of dependencies,
  only a superset, or the same),

- launch a stale `git-bugreport` from a completely different Git,

- make users angry for wasting 3MB of their diskspace for `git-bugreport`
  when only a dozen kilobyte would suffice.

On the other hand, if we make `git-bugreport` a built-in, I cannot see any downsides.

For me, therefore, having it as a built-in is a clear win. What am I missing?

Ciao, Dscho