Re: [PATCH v3] hooks: introduce 'hooks.allowNoVerify' configuration

On 2026-09-02 at 17:23:14, Alessio Attilio via GitGitGadget wrote:

From: Alessio Attilio <redacted>

Introduce the 'hooks.allowNoVerify' configuration variable to control
whether the '--no-verify' (or '-n') command-line option is permitted
during operations executing client-side hooks (commit, push, merge,
rebase, am).

Client-side hooks execute in the user's local repository and cannot serve
as an authoritative security boundary; authoritative policy enforcement
belongs on the server (such as via pre-receive hooks). However,
developers often invoke '--no-verify' out of habit or muscle memory,
inadvertently skipping local checks.

I agree with Junio that this doesn't seem like a good idea.  It's up to
the user whether they want to install or use hooks and they are free to
disable them or override them as they see fit.  If the user doesn't want
to use local hooks on an individual case basis, then `--no-verify` is
the right option.

In my case, I use hooks for Git LFS when I use that software, but I
never use repository owner-provided hooks, although I may use my own. As
a result, I almost never use `--no-verify`.

If in your environment you are trying to force developers to use local
hooks, the Git FAQ mentions that this is not an effective control and
you should stop trying to do that.  In fact, I would even argue that you
should simply not install hooks by default for repositories using your
scripts or build tools because it's up to users whether those are useful
for them.  The Git FAQ mentions reasons why forced installation of hooks
is harmful for many workflows and I don't think we should be hassling
users like that.

In any event, it's trivial to simply bypass all hooks by setting
`core.hooksPath` to `/dev/null` using a variety of different techniques.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA