Re: [PATCH v3 4/7] repo: add path.hooks with absolute and relative suffix formatting

[Justin Tobler <jltobler@gmail.com>]

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