Re: [PATCH v9 2/5] bugreport: add tool to generate debugging info
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Mar 21, 2020, 10:53 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2003211152080.46@tvgsbejvaqbjf.bet>
- In-Reply-To
- <xmqq7dzebq4j.fsf@gitster.c.googlers.com>
Hi Junio,
On Fri, 20 Mar 2020, Junio C Hamano wrote:
Show 22 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> I actually have a suspicion that "git bugreport" that is spawned via > >> "git" wrapper is a bad idea (in other words, /usr/bin/git-bug that > >> is totally standalone may be better). > > > > The obvious downside of `/usr/bin/git-bug`, of course, is that it has no > > way to provide accurate data regarding, say, the cURL version in use. > > Sorry, but I do not see what's new in your argument this time. > > I thought we've already established that the best solution for the > "accurate data regarding, say, the cURL version in use" is to use > your earlier idea, i.e. give an interface to git-remote-curl so that > "git bugreport" can ask it such details, because "git bugreport" > that is known by git.c::cmd_main(), whether it is builtin or > standalone, is *NOT* linked to the transport anyway. > > And the same interface can be used by an independent "git-bug", or > even by the end user who is sitting at a terminal when asked by git > developers "what version of curl library does your build link > with?".
You are _asking_ for version mismatch here. If `git-bug` is a totally standalone program, then it cannot rely at all on `git` to give it the information it wants. Forward compatibility becomes another concern.
In other words, all the avoidably incurred complexity will come back to make the entire `git bugreport` not worth all the effort Emily put into it.
Ciao, Dscho