Hi Stolee
On 14/04/2025 11:59, Derrick Stolee wrote:
On 4/4/2025 10:15 AM, Phillip Wood wrote:
On 03/04/2025 23:38, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee <stolee@xxxxxxxxx>
To that end, add a new --no-hooks global option to allow users to
disable hooks quickly. This option is modeled similarly to the
--no-advice option in b79deeb554 (advice: add --no-advice global option,
2024-05-03). This uses a GIT_HOOKS environment variable to communicate
to subprocesses as well as making this a backwards-compatible way for
tools to signal that they want to disable hooks.
The critical piece is that all hooks pass through run_hooks_opt() where
a static int will evaluate the environment variable and store that the
variable is initialized for faster repeated runs.
That certainly makes the implementation much more viable. However I'm
not really convinced this is a good idea.
I don't read a strong reason in your message that this is a _bad_
idea either. As in, there's nothing that hints that this will cause
significant harm to users other than providing a new footgun (and we
have plenty of those for folks willing to look, including the
_existence_ of hooks).
It is certainly not a terrible idea given that it is possible to disable
hooks already but I'm not clear what the motivation is. I don't find the
example of a skipping a pre-commit hook persuasive as we already provide
a convenient way for users to skip that hook. Elsewhere in this thread
you mention the "pre-command" and "post-command" hooks but they are not
part of git - if a fork is running its own hooks and that is causing
problems for users I'm not sure we want to change the upstream project
to address that. If there was a clearer motivation it would be easier to
understand the benefits of this change.
Best Wishes
Phillip
