From: Junio C Hamano <gitster@pobox.com>
To: Mark Levedahl <mlevedahl@gmail.com>
Cc: johannes.schindelin@gmx.de, me@yadavpratyush.com, git@vger.kernel.org
Subject: Re: [PATCH] git-gui - re-enable use of hook scripts
Date: Sat, 16 Sep 2023 10:28:48 -0700 [thread overview]
Message-ID: <xmqqy1h6auy7.fsf@gitster.g> (raw)
In-Reply-To: <20230916003516.51053-1-mlevedahl@gmail.com> (Mark Levedahl's message of "Fri, 15 Sep 2023 20:35:16 -0400")
Mark Levedahl <mlevedahl@gmail.com> writes:
> Commit aae9560a introduced search in $PATH to find executables before
> running them, avoiding an issue where on Windows a same named file in
> the current directory can be executed in preference to anything on the
> path. The updated search excludes files given with an absolute path (e.g.,
> /bin/sh). However this change precludes operation of hook scripts as these
> are named with a relative path (.git/hooks/$HOOK), while a search on $PATH
> can succeed only for bare file names, not relative paths. Furthermore,
> the current repository's .git/hooks directory is in general not listed
> in PATH.
>
> Fix this by changing the "absolute" check to a check for more than one
> component in the pathname, thereby avoiding the PATH check for anything
> given with a relative path as well. Bare "git" has one component, "/sh"
> has two components, and .git/hooks/$HOOK has more than two, so relative
> and absolute pathnames avoid the check.
>
> Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
> ---
With your experiments in the other thread, I think this is quite a
reasonable fix to the problem. I'd prefer a few updates to the
proposed log message above, though.
* Refer the older commit like so:
Earlier, aae9560a (Work around Tcl's default `PATH` lookup,
2022-11-23) introduced ...
* It would help readers if you clarify that "The updated search
excludes ..." and the rest of that paragraph of the log gives a
bug/problem/undesirable behaviour of the current code introduced
by the earlier change. Perhaps something along the lines of ...
The updated search excludes commands given as an absolute
path (e.g., /bin/sh), which is good, but it also tries to
find commands given as a path relative to the current
directory with directory separator (e.g.,
.git/hooks/pre-commit), which makes the hooks from running
at all. We only want to apply the $PATH logic to a token
without any directory separator in it.
* Mention that we already know the new logic works for absolute
paths even on Windows by tweaking the sentence starting with
"Bare 'git' has ...". Something like:
Bare "git" has one component (which we want to use $PATH),
"/bin/sh", "C:\some\command", and ".git/hooks/$HOOK" all
split into 2 or more (which we want to use as-is). The only
case we want to use $PATH is when result of [file split] has
only one element.
But other than that it looks good.
Dscho?
> git-gui.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-gui.sh b/git-gui.sh
> index 8bc8892..8603437 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -118,7 +118,7 @@ proc sanitize_command_line {command_line from_index} {
> set i $from_index
> while {$i < [llength $command_line]} {
> set cmd [lindex $command_line $i]
> - if {[file pathtype $cmd] ne "absolute"} {
> + if {[llength [file split $cmd]] < 2} {
> set fullpath [_which $cmd]
> if {$fullpath eq ""} {
> throw {NOT-FOUND} "$cmd not found in PATH"
next prev parent reply other threads:[~2023-09-16 17:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-15 16:45 BUG: git-gui no longer executes hook scripts Mark Levedahl
2023-09-15 17:00 ` Junio C Hamano
2023-09-15 17:15 ` Junio C Hamano
2023-09-15 23:33 ` Mark Levedahl
2023-09-16 0:35 ` [PATCH] git-gui - re-enable use of " Mark Levedahl
2023-09-16 17:28 ` Junio C Hamano [this message]
2023-09-16 21:01 ` [PATCH v2] " Mark Levedahl
2023-09-16 21:51 ` Junio C Hamano
2023-09-17 19:22 ` Mark Levedahl
2023-09-17 19:24 ` [PATCH] git-gui - use git-hook, honor core.hooksPath Mark Levedahl
2023-09-18 15:27 ` Johannes Schindelin
2023-09-18 15:58 ` Junio C Hamano
2023-09-18 16:25 ` Mark Levedahl
2023-09-18 17:53 ` Junio C Hamano
2023-09-20 13:05 ` Pratyush Yadav
2023-09-20 15:30 ` Mark Levedahl
2023-09-20 16:58 ` Junio C Hamano
2023-09-20 15:49 ` Junio C Hamano
2023-09-18 15:26 ` [PATCH v2] git-gui - re-enable use of hook scripts Johannes Schindelin
2023-09-18 16:04 ` Junio C Hamano
2023-09-20 13:27 ` Pratyush Yadav
2023-09-16 4:45 ` BUG: git-gui no longer executes " Junio C Hamano
2023-09-16 12:56 ` Mark Levedahl
2023-09-16 14:49 ` Mark Levedahl
2023-09-16 17:31 ` Junio C Hamano
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=xmqqy1h6auy7.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=me@yadavpratyush.com \
--cc=mlevedahl@gmail.com \
/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.