From: Junio C Hamano <gitster@pobox.com>
To: "D. Ben Knoble" <ben.knoble+github@gmail.com>
Cc: git@vger.kernel.org,
"Johannes Schindelin" <johannes.schindelin@gmx.de>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH 4/4] drop git_exec_path() from non-Git commands' PATH
Date: Tue, 20 May 2025 13:33:08 -0700 [thread overview]
Message-ID: <xmqqy0urggzf.fsf@gitster.g> (raw)
In-Reply-To: <20250520193506.95199-5-ben.knoble+github@gmail.com> (D. Ben Knoble's message of "Tue, 20 May 2025 15:34:58 -0400")
"D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
> We setup_path() with git_exec_path() unconditionally (8e3462837b (Modify
> setup_path() to only add git_exec_path() to PATH, 2009-01-18)) when Git
> starts; as a result, all child processes see Git's exec-path when run,
> including editors and other programs that don't need it [1]. This can
> cause confusion for such programs or shells, especially when they rely
> on finding "git" in PATH to locate other nearby directories, in a
> similar vein as a0b4507ef7 (stop putting argv[0] dirname at front of
> PATH, 2015-04-22) solved.
I can understand why we want to do this for things like editors, but
doing this in start_command() would affect running of things like
hook scripts (which may in turn invoke "git" commands) and command
running on the other side of the pipe that does a local transport
(e.g., "git fetch --upload-pack cmd"), and other commands specified
via the configuration (e.g., "trailer.<key>.cmd") that may in turn
invoke "git" commands, wouldn't it?
> @@ -746,7 +789,7 @@ int start_command(struct child_process *cmd)
> if (cmd->close_object_store)
> close_object_store(the_repository->objects);
>
> - childenv = prep_childenv(cmd->env.v);
> + childenv = prep_childenv(cmd->env.v, cmd->git_cmd);
Regardless of the answer to the above question, I wonder if the API
change for this helper function should go the other direction, by
passing the entire "child_process" structure to the function. That
would give prep_childenv() more information to work with to decide
when futzing with PATH is appropriate.
Yes, I am assuming that the answer to the above question is "true,
unconditionally futzing with PATH is a bad idea" and we need this
fix to be more focused, e.g., limit to "launch_specified_editor()".
If that is the case, we can
- add a member "drop_git_exec_path" bit to "struct child_process";
- update selected callers, e.g., launch_specified_editor(), that
prepare child_process to set that bit;
- update prep_childenv() to accept the entire "struct child_process",
instead of cmd->env.v, and base the decision in your logic to
look at the cmd->drop_git_exec_path bit;
perhaps. It would give us a more surgical and focused update,
hopefully?
next prev parent reply other threads:[~2025-05-20 20:33 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 19:34 [PATCH 0/4] Drop git-exec-path from non-Git child programs D. Ben Knoble
2025-05-20 19:34 ` [PATCH 1/4] t7005: sanitize test environment for subsequent tests D. Ben Knoble
2025-05-21 7:56 ` Patrick Steinhardt
2025-05-21 13:23 ` D. Ben Knoble
2025-05-20 19:34 ` [PATCH 2/4] editor: use standard strvec API to receive environment for external editors D. Ben Knoble
2025-05-21 7:56 ` Patrick Steinhardt
2025-05-21 13:26 ` D. Ben Knoble
2025-05-21 13:34 ` Patrick Steinhardt
2025-05-21 15:20 ` Junio C Hamano
2025-05-21 15:10 ` Junio C Hamano
2025-05-20 19:34 ` [PATCH 3/4] run-command: prep_childenv on all platforms D. Ben Knoble
2025-05-21 7:56 ` Patrick Steinhardt
2025-05-21 13:07 ` Phillip Wood
2025-05-21 13:33 ` D. Ben Knoble
2025-05-20 19:34 ` [PATCH 4/4] drop git_exec_path() from non-Git commands' PATH D. Ben Knoble
2025-05-20 20:33 ` Junio C Hamano [this message]
2025-05-21 13:44 ` D. Ben Knoble
2025-05-21 8:27 ` Patrick Steinhardt
2025-05-21 13:07 ` Phillip Wood
2025-05-21 13:17 ` Patrick Steinhardt
2025-05-21 15:27 ` Phillip Wood
2025-05-26 6:34 ` Patrick Steinhardt
2025-05-21 15:50 ` Justin Tobler
2025-05-26 6:31 ` Patrick Steinhardt
2025-05-21 13:48 ` D. Ben Knoble
2025-05-21 14:47 ` Junio C Hamano
2025-05-22 13:21 ` [PATCH 0/4] Drop git-exec-path from non-Git child programs Phillip Wood
2025-08-05 1:41 ` D. Ben Knoble
2025-08-05 2:40 ` [PATCH 0/2] clean up some code around editors D. Ben Knoble
2025-08-06 10:07 ` Phillip Wood
2025-08-05 2:40 ` [PATCH 1/2] t7005: sanitize test environment for subsequent tests D. Ben Knoble
2025-08-05 2:40 ` [PATCH 2/2] editor: use standard strvec API to receive environment for external editors D. Ben Knoble
2025-08-10 16:03 ` [PATCH 0/3] clean up some code around editors D. Ben Knoble
2025-08-10 16:06 ` D. Ben Knoble
2025-08-10 16:34 ` Ben Knoble
2025-08-11 22:16 ` [PATCH v3 0/4] " D. Ben Knoble
2025-08-11 22:59 ` Ben Knoble
2025-08-12 0:16 ` Eric Sunshine
2025-08-12 16:42 ` D. Ben Knoble
2025-08-12 17:35 ` Junio C Hamano
2025-08-12 18:13 ` Eric Sunshine
2025-08-12 18:22 ` Junio C Hamano
2025-08-12 18:30 ` Eric Sunshine
2025-08-12 17:02 ` [PATCH v4 0/3] " D. Ben Knoble
2025-08-13 10:14 ` Phillip Wood
2025-08-13 15:41 ` Junio C Hamano
2025-08-13 17:36 ` D. Ben Knoble
2025-08-13 17:50 ` [PATCH v5 " D. Ben Knoble
2025-08-15 16:00 ` Phillip Wood
2025-08-13 17:50 ` [PATCH v5 1/3] t7005: use modern test style D. Ben Knoble
2025-08-13 17:50 ` [PATCH v5 2/3] t7005: stop abusing --exec-path D. Ben Knoble
2025-08-13 17:50 ` [PATCH v5 3/3] t7005: sanitize test environment for subsequent tests D. Ben Knoble
2025-08-12 17:02 ` [PATCH v4 1/3] t7005: use modern test style D. Ben Knoble
2025-08-12 17:02 ` [PATCH v4 2/3] t7005: stop abusing --exec-path D. Ben Knoble
2025-08-12 17:02 ` [PATCH v4 3/3] t7005: sanitize test environment for subsequent tests D. Ben Knoble
2025-08-11 22:16 ` [PATCH v3 1/4] t7005: use modern test style D. Ben Knoble
2025-08-11 22:16 ` [PATCH v3 2/4] t7005: stop abusing --exec-path D. Ben Knoble
2025-08-11 22:16 ` [PATCH v3 3/4] t7005: sanitize test environment for subsequent tests D. Ben Knoble
2025-08-11 22:34 ` Eric Sunshine
2025-08-12 16:40 ` D. Ben Knoble
2025-08-12 17:13 ` Eric Sunshine
2025-08-11 22:16 ` [PATCH v3 4/4] editor: use standard strvec API to receive environment for external editors D. Ben Knoble
2025-08-11 22:46 ` Eric Sunshine
2025-08-11 23:58 ` Junio C Hamano
2025-08-10 16:03 ` [PATCH 1/3] t7005: use modern test style D. Ben Knoble
2025-08-10 19:42 ` Phillip Wood
2025-08-11 10:04 ` Phillip Wood
2025-08-10 16:03 ` [PATCH 2/3] t7005: sanitize test environment for subsequent tests D. Ben Knoble
2025-08-10 19:44 ` Phillip Wood
2025-08-10 19:53 ` Ben Knoble
2025-08-10 20:58 ` Eric Sunshine
2025-08-11 9:59 ` Phillip Wood
2025-08-10 16:03 ` [PATCH 3/3] editor: use standard strvec API to receive environment for external editors D. Ben Knoble
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=xmqqy0urggzf.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=ben.knoble+github@gmail.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).