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

From: Justin Tobler <jltobler@gmail.com>
Date: Jul 28, 2026, 19:00 UTC
Message-ID: <amjjMwAHSbkQgtPb@denethor>
In-Reply-To: <20260726104343.16933-5-jayatheerthkulkarni2005@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