]> git.ipfire.org Git - thirdparty/git.git/commit
git-gui: use dashless 'git cmd' form for read/write
authorMark Levedahl <mlevedahl@gmail.com>
Sat, 5 Apr 2025 03:08:35 +0000 (23:08 -0400)
committerMark Levedahl <mlevedahl@gmail.com>
Mon, 21 Jul 2025 22:22:33 +0000 (18:22 -0400)
commit6dfdf7bdcdcf735787e3d3dfcf3415fea1a81f8a
treef25fb321b65d650c131a63a7f814a462d135ea80
parent3ce650f4c93f9f3aacdb6a1d8cef21bb2009bfa3
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>
git-gui.sh