Hi Junio, On Fri, 20 Mar 2020, Junio C Hamano wrote: > Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > > > This is the kind of stuff I really wanted to get straightened out by > > sending the smaller changeset, so I'm glad to be having this > > conversation (again, and hopefully for the last time). > > 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. That's a pretty severe downside if you are truly interested in helping bug reporters and bug receivers. Ciao, Dscho > > The thing is, anything launched by "git" as its subcommand (be it > standalone or builtin) sees an environment already modified by > "git", so inspecting say "$PATH" from "git bugreport" (be it > standalone or builtin) does not show what the end-user, who may be > having trouble, actually has. The mangling of $PATH alone happens > to be simple and (we may think) we can easily reverse without losing > bits, but there would probably other differences that we think is so > subtle and insignificant, right now in this discussion without > having actual end-user who is having trouble in front of us, that > having "git" layer in between may hide from us. > > Having "git-bug" a totally separate tool, that does not even go > through git.c::cmd_main(), would also allow (and force) us to treat > "git" just like any system component on the end-users' system whose > versions and configurations may affect the use of "git" by the end > user. The tool, instead of relying on git_version_string[] that is > determined at the compile time, would ask "git version" just like > the end-users would when asked by us "what version of git do you > run?" It also means that "git-bug" can be updated at different > cadence and the mismatch of versions between it and "git" does not > matter at all. > > Having said all that, after suggesting to make the tool even more > distant from the remainder of the binary, quite honestly, I do not > even want to see us wasting any more time on builtin/standalone at > this point, and instead would like to see reports from the end-users > produced by a lets-start-small version of the tool and measure how > having the tool actually helps. > > Thanks. >
