From: Jeff King <firstname.lastname@example.org> To: Junio C Hamano <email@example.com> Cc: Derrick Stolee <firstname.lastname@example.org>, email@example.com, Emily Shaffer <firstname.lastname@example.org>, 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: <email@example.com> On Thu, Aug 13, 2020 at 11:47:29AM -0700, Junio C Hamano wrote: > Junio C Hamano <firstname.lastname@example.org> writes: > > > Jeff King <email@example.com> 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
next prev parent 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 \ --firstname.lastname@example.org \ --cc=Johannes.Schindelin@gmx.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).