diff options
author | Mark Levedahl <mlevedahl@gmail.com> | 2025-04-04 23:08:35 -0400 |
---|---|---|
committer | Mark Levedahl <mlevedahl@gmail.com> | 2025-07-21 18:22:33 -0400 |
commit | 6dfdf7bdcdcf735787e3d3dfcf3415fea1a81f8a (patch) | |
tree | f25fb321b65d650c131a63a7f814a462d135ea80 /git-gui/lib/commit.tcl | |
parent | 3ce650f4c93f9f3aacdb6a1d8cef21bb2009bfa3 (diff) |
git-gui: use dashless 'git cmd' form for read/write
git-gui implements its own approach to locating and running various git
subcommands, bypassing git's capabilities for running git-*. This was
written in 2007: at that time, many git commands were shell-scripts
stored in $(git --exec-path), git's run-command api was not well adapted
to Windows and had serious performance issues when it worked at all, and
running subcommand 'git foo' as 'git-foo' was common and fully supported.
On Windows, git-gui searches $(git --exec-path) for builtin commands,
then attempts to find an interpreter on PATH to run those, invoking
these differently than on other platforms. For instance, the explicit
shebang #!/usr/bin/perl found in a script will be run by the first Perl
interpreter found on $PATH, which might not be at that specific location
so could be different than what git would run.
The various issues leading to the current implemention no longer exist.
Most git commands are now builtins, links to run those are not installed
in $(git --exec-path) by default (the "dashless" form is recommended
instead), and git's run-command api works well everywhere.
So, let's use git to launch its subcommands on all platforms. Do so by
modifying procs git_read and git_write to use the "dashless" form for
invoking git commands, avoiding the search for git-<foo>. This leaves
_git_cmd unused with cleanup in a later patch.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Diffstat (limited to 'git-gui/lib/commit.tcl')
0 files changed, 0 insertions, 0 deletions