On 9/20/23 09:05, Pratyush Yadav wrote:
In the past, git-gui has tried to keep backward compatibility with all
versions of Git, not just the latest ones. v2.36 is relatively new and
this code would not work for anyone using an older version of Git.
I have largely followed this practice for all the code I have written
but I am not sure if it is a good idea to insist on it -- especially if
it would end up adding some more complexity. I would be interested to
hear what other people think about this.
I am not aware of any distribution (Linux, g4w, Mac) shipping anything
except the git-gui in Junio's tree, which is specific to the git-core
version, and the git-gui packages require (or are a part of) the same
version git-core package: no cross-version compatibility of git
components is assumed. Certainly, folks rolling their own can pull from
upstream git-gui, but they take the risk of incompatibility with an
outdated git. Other tools in Junio's tree have already made the switch
to git-hook (send-email, git-p4) even though they are usually packaged
separately from git-core, but also version locked to matching git-core.
Updating git-gui's hook execution to match git internals would be more
complex than what I implemented or what was there before. For instance,
I never looked at what git-hook's g4w compatibility code uses to test if
a hook is present and executable, it wouldn't surprise me to find
git-gui was missing something there, but who wants to bother? Also, the
commit language surrounding addition of git-hook is strongly suggestive
of other changes in configuration coming, meaning more changes to hook
execution code would be needed that are avoided by using git-hook. Note:
I have one more patch to send, removing yet another work-around for
early Cygwin tcl/tk, as more evidence of how many years it takes to
clean some of this stuff out and the difficulty of keeping git-gui up to
date.
I had considered the above when creating the patch, and I believe what I
did is the right approach.
Mark
