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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.