referencing the upstream gitk repo at published at
https://github.com/j6t/gitk.git:
Since commit 4cbe9e0e2 - "gitk(Windows): avoid inadvertently calling
executables in the worktree,"
gitk no longer works on Cygwin. This commit is in Junio's tree as part
of release v2.49.0, but I didn't trace to the specific merge commit.
The proximal issue is an endless loop caused by routine _which invoking
exec, which is now a wrapper that invokes _which, while the builtin exec
is renamed to real_exec. This results in stack exhaustion. There are
other problems due to munging Cygwin's $PATH into Windows rather than
Unix format, so changing _which to invoke real_exec just changes the
failure mode on Cygwin.
Removing the Cygwin specific code so that gitk treats Cygwin as a Linux
variant does work: e.g.,
diff --git a/gitk b/gitk
index bc9efa1..2c29118 100755
--- a/gitk
+++ b/gitk
@@ -49,14 +49,7 @@ proc _which {what args} {
global env _search_exe _search_path
if {$_search_path eq {}} {
- if {[is_Cygwin] && [regexp {^(/|\.:)} $env(PATH)]} {
- set _search_path [split [exec cygpath \
- --windows \
- --path \
- --absolute \
- $env(PATH)] {;}]
- set _search_exe .exe
- } elseif {[is_Windows]} {
+ if {[is_Windows]} {
set gitguidir [file dirname [info script]]
regsub -all ";" $gitguidir "\\;" gitguidir
set env(PATH) "$gitguidir;$env(PATH)"
However, the above leaves code in place affecting path search on all
platforms without justification. The commit message references the TCL
man page for "exec", listing a number of directories (including the
current working directory) and file suffixes searched on the Windows
platform that could be problematic. However, that man page does not list
any such issues for other platforms. So, it appears the patch does not
address a known issue on Unix platforms, which includes Cygwin.
I believe the correct fix to 4cbe9e0e2 is limiting the override of exec
and open to Windows, and I also have a patch to do that rather than what
I show above. Let me know.
Mark
