Hi,

On Fri, 2 Jun 2017, Ævar Arnfjörð Bjarmason wrote:

> On Fri, Jun 2, 2017 at 3:41 PM, Philipp Gortan <philipp@gortan.org> wrote:
>
> > I've been unhappy for quite a while that I had to configure the hooks
> > manually for each of my repos - until I found out recently that there
> > is the core.hooksPath config variable that (when set globally) allows
> > me to specify a hooks directory to be used for all my repositories.
> >
> > Now I was happy - for a few minutes, until I tested this feature in
> > git-gui, and realized that it doesn't work there.
> >
> > This seems to be caused by "proc githook_read", which says "set pchook
> > [gitdir hooks $hook_name]" instead of querying "git config
> > core.hooksPath" first - cf
> > https://github.com/git/git/blob/2cc2e70264e0fcba04f9ef791d144bbc8b501206/git-gui/git-gui.sh#L627
> >
> > Would be great if this could get fixed...

Indeed. Why don't you give it a try?

> This indeed is something that should be fixed, but git-gui development
> is managed outside of git.git, it's just occasionally pulled in. I'm
> not what the best place to contact is, but I've CC'd
> Philip Oakley who's been making recent commits to git-gui.git at
> http://repo.or.cz/git-gui.git/

Philip is in the same spot as I am: we both worked on Git GUI to improve
it for Git for Windows users, but Pat has been silent for over half a year
on all of our PRs.

In the meantime, I managed to get a couple of changes into git.git via
Junio, but the situation is far from ideal.

So what I settled on is to carry a couple of Git GUI patches in Git for
Windows' fork, until the time when the patches finally get accepted into
https://github.com/patthoyts/git-gui.

In this particular instance, the only question is whether to use `git
rev-parse --git-path hooks` or re-roll the core.hookspath logic in
git-gui.

Both approaches have their downsides:

- rev-parse --git-path was broken in subdirectories for a *really* long
  time. Since Git GUI is supposed to be relatively independent from the
  version of the installed git executable, that would imply a couple of
  ugly extra code just to make sure that it works correctly.

- duplicating the core.hookspath logic is prone to become stale over time,
  as Git may change the behavior (as it did with the core.hookspath
  setting).

The subdirectory problem of --git-path is actually not that bad, as Git
GUI cd's to the top-level directory anyway. So that bug does not affect
us. The only caveat is that --git-path was only introduced into v2.5.0,
and Git GUI has conditional code to even support pre-1.6.3 versions.

Happily, pre-1.6.3 versions are not supposed to handle core.hookspath in
the way v2.9.0 and later handle it.

So something like this *may* work:

-- snip --
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 37c1c5d227b..3067a3b000a 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -624,7 +624,11 @@ proc git_write {args} {
 }
 
 proc githook_read {hook_name args} {
-	set pchook [gitdir hooks $hook_name]
+	if {[package vcompare $::_git_version 2.5.0] >= 0} {
+		set pchook [git rev-parse --git-path "hooks/$hook_name"]
+	} else {
+		set pchook [gitdir hooks $hook_name]
+	}
 	lappend args 2>@1
 
 	# On Windows [file executable] might lie so we need to ask
-- snap --

Philipp, this is as far as I will go with this. If you truly desire this
to be fixed, please take it from here (read: test, fix and submit with a
good commit message).

Ciao,
Johannes