Hi Junio, On Fri, 20 Mar 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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
