git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Derrick Stolee <stolee@gmail.com>,
	git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 3/5] make git-bugreport a builtin
Date: Fri, 14 Aug 2020 06:13:21 -0400	[thread overview]
Message-ID: <20200814101321.GB3312240@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqr1sa1iym.fsf@gitster.c.googlers.com>

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

  reply	other threads:[~2020-08-14 10:13 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-13 14:55 [PATCH 0/5] slimming down installed size Jeff King
2020-08-13 14:57 ` [PATCH 1/5] Makefile: drop builtins from MSVC pdb list Jeff King
2020-08-13 15:04   ` Taylor Blau
2020-08-13 15:08     ` Jeff King
2020-08-13 16:37       ` Derrick Stolee
2020-08-13 17:40         ` Jeff King
2020-08-14 14:18       ` Johannes Schindelin
2020-08-14 14:32         ` Jeff King
2020-08-17  4:42           ` Johannes Schindelin
2020-08-17 13:20         ` Jeff Hostetler
2020-08-13 14:58 ` [PATCH 2/5] make credential helpers builtins Jeff King
2020-08-13 15:08   ` Taylor Blau
2020-08-13 15:14     ` Jeff King
2020-08-13 17:55       ` Junio C Hamano
2020-08-13 14:59 ` [PATCH 3/5] make git-bugreport a builtin Jeff King
2020-08-13 17:01   ` Derrick Stolee
2020-08-13 17:38     ` Jeff King
2020-08-13 18:25       ` Junio C Hamano
2020-08-13 18:47         ` Junio C Hamano
2020-08-14 10:13           ` Jeff King [this message]
2020-08-14 14:25           ` Johannes Schindelin
2020-08-14 10:05         ` Jeff King
2020-08-13 18:01   ` Junio C Hamano
2020-08-14 14:28     ` Johannes Schindelin
2020-08-15  6:38     ` Jeff King
2020-08-17 12:12       ` Emily Shaffer
2020-08-17 16:58       ` Junio C Hamano
2020-08-17 21:40         ` Jeff King
2020-08-17 12:16   ` Emily Shaffer
2020-08-13 14:59 ` [PATCH 4/5] make git-fast-import " Jeff King
2020-08-13 15:00 ` [PATCH 5/5] drop vcs-svn experiment Jeff King
2020-08-13 15:11   ` Taylor Blau
2020-08-13 15:18     ` Jeff King
2020-08-14 14:39   ` Johannes Schindelin
2020-08-14 15:11     ` Jeff King
2020-08-13 15:13 ` [PATCH 0/5] slimming down installed size Taylor Blau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200814101321.GB3312240@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=stolee@gmail.com \
    --subject='Re: [PATCH 3/5] make git-bugreport a builtin' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).