Re: [PATCH 3/5] make git-bugreport a builtin

[Jeff King <peff@peff.net>]

On Thu, Aug 13, 2020 at 11:47:29AM -0700, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Jeff King <peff@peff.net> writes:
> >
> >>     macros). That could change eventually of course, but it's not like
> >>     switching back to a stand-alone at that point is a big deal.
> >
> > If it is not a big deal, then I am fine, but at the same time it
> > becomes unclear why we can say "we can use X and Y niceties only
> > available for builtins".
> 
> Actually, there is another issue that is potentially a lot worse.
> 
> "git bugreport" not being built-in would mean that the compiled-in
> git-version MUST not be relied upon (it merely is a version of the
> source "git bugreport" came from, it does not necessarily match the
> main "git" binary when we are dealing with a confused user with
> GIT_EXEC_PATH problem), but has to be asked to "git" binary on the
> $PATH externally.  That needs to be done for any non-builtin
> binaries (e.g. when user is having issue with git-remote--curl")
> anyway, keeping "git bugreport" out of builtin would force us the
> necessary discipline from early on.

I'm skeptical that an external program would help at all there. If you
say "git bugreport" you are going to get the "git" on your PATH. If it's
a builtin, then obviously we'd run that version. If it's not, then it
would run the first one from GIT_EXEC_PATH. That would normally be the
matching version. If there's a misconfiguration where that is not true,
then I'd argue the builtin version is likely to produce a better
response anyway.

If there were some mechanism by which that caused a failure that we
might notice and correct, I'd agree with your "necessary discipline"
comment. But in practice I think that:

  - it will either not matter for the details collected in the bug
    report, in which case nobody will notice the misconfiguration anyway

  - it will lead to confusing details in the report, at which point
    people will work manually with the submitter to figure out what is
    going on (just like they do now)

But I don't see a way that it systematically identifies such
misconfigurations or helps us avoid them. If it is a type of issue that
comes up a lot, then that's something the tool ought to be examining
systematically (looking at GIT* in the environment, reporting the
baked-in exec path, etc). Trying to glean that from behavior differences
in an external bugreport program sounds fragile and confusing.

-Peff