Re: [PATCH v3 4/7] repo: add path.hooks with absolute and relative suffix formatting
Justin Tobler <[email protected]> Tue, 28 Jul 2026 14:00:29 -0500
| Newsgroups | org.kernel.vger.git |
|---|---|
| Message-ID | <amjjMwAHSbkQgtPb@denethor> |
On 26/07/26 04:13PM, K Jayatheerth wrote: > External tool integrations and validation systems need a stable way to > identify where the repository hooks are stored. Currently, this involves > relying on `git rev-parse --git-path hooks` or querying `core.hooksPath` > manually. Similar to the comment in the previous patch, "External tool intergations and validation systems" seems overly specific IMO. Also, "need" is a bit strongly worded as I'm sure its not a requirement for every external script/tool. > Introduce `path.hooks.absolute` and `path.hooks.relative` keys to > `git repo info`. This allows tools to discover the active hooks location > natively, ensuring proper resolution regardless of whether Git is using > the standard `.git/hooks` structure or a custom `core.hooksPath` setup. Per hooks path documentation: The path can be either absolute or relative. A relative path is taken as relative to the directory where the hooks are run. ... You can also disable all hooks entirely by setting core.hooksPath to /dev/null. Should we handle this /dev/null case specially? It looks like: $ git -c core.hooksPath=/dev/null rev-parse --git-path hooks just prints '/dev/null'. I do wonder if this makes much sense though in context of the relative path version of this key. From some quick testing, it appears the git-rev-parse(1) version of this option always prints the absolute path if that is what is configured (it appears to ignore --path-format). Maybe we should just special case /dev/null and return an empty string? I'm not entirely sure what the best route is here though. -Justin