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