From: Alessio Attilio <alessio.attilio@protonmail.com>

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,
accidentally skipping local checks.

To address both 'security theatre' concerns and avoid breaking legitimate
emergency escape hatches ('big red button'), this implementation:

1. Introduces granular values:
   - 'true' (or 'always', default): '--no-verify' is permitted normally.
   - 'warn': '--no-verify' is permitted, but prints a warning to stderr.
   - 'false' (or 'never', 'error'): '--no-verify' is disallowed by default.

2. Preserves the emergency break-glass escape hatch:
   When configured to 'false', Git does not create a dead-end. It outputs
   actionable advice explaining that the setting is a workflow guardrail
   against accidental bypass, and documents how to override it in an
   emergency via 'GIT_ALLOW_NO_VERIFY=1' or '-c hooks.allowNoVerify=true'.
   This eliminates the need for developers to resort to destructive local
   hacks like deleting hooks or chmod -x.

3. Centralizes the validation logic in 'hook.c' and 'hook.h' via
   validate_no_verify().

Signed-off-by: Alessio Attilio <alessio.attilio@protonmail.com>

Submitted-As: https://lore.kernel.org/git/pull.2215.v2.git.1788366925041.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2215.git.1788365862670.gitgitgadget@gmail.com