Re: [GSoC Patch v7 4/8] repo: add path.hooks with absolute and relative suffixes

[Justin Tobler <jltobler@gmail.com>]

On 26/11/03 08:01AM, K Jayatheerth wrote:
> On Tue, Nov 3, 2026 at 4:02 AM Justin Tobler <jltobler@gmail.com> wrote:
> >
> > So if a repository has `core.hooksPath` set to "/dev/null", the relative
> > path output here would be something like "../../../../dev/null". I
> > recognize that this matches the current behavior:
> >
> >   $ git -c core.hooksPath=/dev/null rev-parse --path-format=relative --git-path hooks
> >   ../../../../dev/null
> >
> > ...but I'm still not really convinced that is is a behavior we would
> > want to carry over as it makes it harder to users to figure out when
> > hooks are disabled.
> >
> > I would suggest we print the "/dev/null" here even when the relative
> > path is requested and document the behavior.
> >
> 
> I am more inclined with you, and
> I see how returning "/dev/null" for the relative key makes it
> much easier for scripts to detect when hooks are disabled.
> 
> One thing I wanted to check: in a follow-up series, Junio suggested
> extracting a common helper library to share implementations between
> `git rev-parse` and `git repo info`. If `git repo info` special-cases
> "/dev/null" for `path.hooks.relative` while `rev-parse --git-path hooks`
> continues to relative-format it, would that divergence be an issue for
> sharing the underlying helper, or should we special-case it only in the
> `path.hooks` getter?

I don't really think that would be an issue. Regarding the follow-up
series, I figure you could just not use a shared helper here if the
behavior is diverged, or special case it some way.

-Justin