From: Phillip Wood Date: Wed, 16 Apr 2025 10:29:13 GMT Subject: Re: [PATCH] git: add --no-hooks global option Message-ID: In-Reply-To: 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 >>> >>> 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