From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,
"brian m. carlson" <sandals@crustytoothpaste.net>,
Phillip Wood <phillip.wood123@gmail.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v2 7/7] var(win32): do report the GIT_SHELL_PATH that is actually used
Date: Fri, 12 Jul 2024 08:35:03 -0700 [thread overview]
Message-ID: <xmqqikxaoc7s.fsf@gitster.g> (raw)
In-Reply-To: <8bfd23cfa00c351ffdcc25bd29f3b84089544a56.1720739496.git.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Thu, 11 Jul 2024 23:11:36 +0000")
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> On Windows, Unix-like paths like `/bin/sh` make very little sense. In
> the best case, they simply don't work, in the worst case they are
> misinterpreted as absolute paths that are relative to the drive
> associated with the current directory.
> To that end, ...
This does not quite explain why a hardcoded full path does not make
sense, though. If you do not want "relative to the current drive",
you can even hardcode the path including the drive letter and now it
no longer falls into that "worst case" because there is no way to
misinterpret it as such. I think the real reason is that the port's
"relocatable" nature does not mix well with the "let's make sure we
know what we use exactly by deciding the paths to various tools at
compile time" mentality. So if I were rerolling this I would say
Git ported to Windows expect to be installed at user-chosen
places, which means hardcoded paths to tools decided at
compile time are bad fit.
or something.
But it does not matter if the stated reason is to use the "find 'sh'
that is on PATH" approach was taken tells the whole story or not.
The important thing is that we do ...
> Git does not actually use the path `/bin/sh` that is
> recorded e.g. when `run_command()` is called with a Unix shell
> command-line. Instead, as of 776297548e (Do not use SHELL_PATH from
> build system in prepare_shell_cmd on Windows, 2012-04-17), it
> re-interprets `/bin/sh` as "look up `sh` on the `PATH` and use the
> result instead".
... this. And with the design constraints that it has to be
installable anywhere and cannot rely on compile-time determined
hardcoded paths, the above design decision is a very valid one.
> This is the logic users expect to be followed when running `git var
> GIT_SHELL_PATH`.
And matching `git var GIT_SHELL_PATH` to what the code path does
make sense.
> diff --git a/builtin/var.c b/builtin/var.c
> index 5dc384810c0..e30ff45be1c 100644
> --- a/builtin/var.c
> +++ b/builtin/var.c
> @@ -12,6 +12,7 @@
> #include "refs.h"
> #include "path.h"
> #include "strbuf.h"
> +#include "run-command.h"
>
> static const char var_usage[] = "git var (-l | <variable>)";
>
> @@ -51,7 +52,7 @@ static char *default_branch(int ident_flag UNUSED)
>
> static char *shell_path(int ident_flag UNUSED)
> {
> - return xstrdup(SHELL_PATH);
> + return git_shell_path();
> }
Simple and clear. Nicely concluded.
Thanks. Will queue.
next prev parent reply other threads:[~2024-07-12 15:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 13:02 [PATCH] var(win32): do report the GIT_SHELL_PATH that is actually used Johannes Schindelin via GitGitGadget
2024-07-08 18:54 ` Junio C Hamano
2024-07-08 23:40 ` brian m. carlson
2024-07-08 23:55 ` Junio C Hamano
2024-07-09 0:25 ` brian m. carlson
2024-07-09 16:31 ` Junio C Hamano
2024-07-09 13:53 ` Phillip Wood
2024-07-08 19:03 ` Junio C Hamano
2024-07-09 8:55 ` Phillip Wood
2024-07-11 12:03 ` Johannes Schindelin
2024-07-17 14:55 ` phillip.wood123
2024-07-11 23:11 ` [PATCH v2 0/7] " Johannes Schindelin via GitGitGadget
2024-07-11 23:11 ` [PATCH v2 1/7] run-command: refactor getting the Unix shell path into its own function Johannes Schindelin via GitGitGadget
2024-07-11 23:11 ` [PATCH v2 2/7] strvec: declare the `strvec_push_nodup()` function globally Johannes Schindelin via GitGitGadget
2024-07-11 23:11 ` [PATCH v2 3/7] win32: override `fspathcmp()` with a directory separator-aware version Johannes Schindelin via GitGitGadget
2024-07-12 13:46 ` Phillip Wood
2024-07-11 23:11 ` [PATCH v2 4/7] mingw(is_msys2_sh): handle forward slashes in the `sh.exe` path, too Johannes Schindelin via GitGitGadget
2024-07-12 13:49 ` Phillip Wood
2024-07-11 23:11 ` [PATCH v2 5/7] run-command(win32): resolve the path to the Unix shell early Johannes Schindelin via GitGitGadget
2024-07-11 23:11 ` [PATCH v2 6/7] run-command: declare the `git_shell_path()` function globally Johannes Schindelin via GitGitGadget
2024-07-11 23:11 ` [PATCH v2 7/7] var(win32): do report the GIT_SHELL_PATH that is actually used Johannes Schindelin via GitGitGadget
2024-07-12 15:35 ` Junio C Hamano [this message]
2024-07-12 13:51 ` [PATCH v2 0/7] " Phillip Wood
2024-07-12 22:16 ` Junio C Hamano
2024-07-13 21:08 ` [PATCH v3 " Johannes Schindelin via GitGitGadget
2024-07-13 21:08 ` [PATCH v3 1/7] run-command: refactor getting the Unix shell path into its own function Johannes Schindelin via GitGitGadget
2024-07-13 21:08 ` [PATCH v3 2/7] strvec: declare the `strvec_push_nodup()` function globally Johannes Schindelin via GitGitGadget
2024-07-13 21:08 ` [PATCH v3 3/7] win32: override `fspathcmp()` with a directory separator-aware version Johannes Schindelin via GitGitGadget
2024-07-13 21:08 ` [PATCH v3 4/7] mingw(is_msys2_sh): handle forward slashes in the `sh.exe` path, too Johannes Schindelin via GitGitGadget
2024-07-13 21:08 ` [PATCH v3 5/7] run-command(win32): resolve the path to the Unix shell early Johannes Schindelin via GitGitGadget
2024-07-13 21:08 ` [PATCH v3 6/7] run-command: declare the `git_shell_path()` function globally Johannes Schindelin via GitGitGadget
2024-07-13 21:08 ` [PATCH v3 7/7] var(win32): do report the GIT_SHELL_PATH that is actually used Johannes Schindelin via GitGitGadget
2024-07-17 14:51 ` [PATCH v3 0/7] " Phillip Wood
2024-07-17 22:47 ` brian m. carlson
2024-07-17 22:51 ` 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=xmqqikxaoc7s.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johannes.schindelin@gmx.de \
--cc=phillip.wood123@gmail.com \
--cc=sandals@crustytoothpaste.net \
/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).