Resolve core.hooksPath relative to GIT_WORK_TREE

[naseschwarz]

git supports a relative path in core.hooksPath.

man git-config:

A relative path is taken as relative to the directory where the hooks are
run (see the "DESCRIPTION" section of githooks[5]).

man githooks:

Before Git invokes a hook, it changes its working directory to either
$GIT_DIR in a bare repository or the root of the working tree in a >
non-bare repository.

I.e. relative paths in core.hooksPath in non-bare repositories are always relative to GIT_WORK_TREE.

There is a further exception; I believe this is not considered for path resolution:

An exception are hooks triggered during a push (pre-receive, update,
post-receive, post-update, push-to-checkout) which are always executed
in $GIT_DIR.

This Pull Request fixes/closes #2281.

It changes the following:

• Synchronizes core.hooksPath resolution with the git command line client

I followed the checklist:

• I added unittests
• I ran make check without errors
• I tested the overall application
• I added an appropriate item to the changelog

[extrawurst]

@Byron this might affect Gitbutler. Would love your pair of eyes

[Byron]

Thanks for calling me in @extrawurst , and thanks @naseschwarz for tackling this!

I'd arrive at the same conclusion on how the implementation should look like, and it's great to see all the right tests.

Of course, I'd have a few nits but they are not material.

It's worth noting that core.hooksPath is very relevant to security on shared drives in particular, and since git2 follows Git and will refuse to open such repositories it should be safe to use core.hooksPath here. In gitoxide one would use trusted_path() instead to obtain the fully-interpolated path if it's in a trusted configuration file.

[naseschwarz]

Thank you for your time and input, @Byron.

[extrawurst]

Thank you!