From: Derrick Stolee Date: Wed, 16 Apr 2025 15:30:51 GMT Subject: Re: [PATCH] git: add --no-hooks global option Message-ID: In-Reply-To: On 4/16/2025 10:28 AM, Junio C Hamano wrote: > Phillip Wood writes: > >>> 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. > > Thanks for pushing back. The default for any new changes is not to > apply unless there is a compelling reason why it is a good idea, > saying that this is not a bad thing does not serve as an effective > justification. > > If we want to give scripters a more stable foundation to build on, > the answer should not be to pile more and more "no hooks, no > configurations, just a vanilla mode of operation" options to > end-user facing porcelain commands, but to clean up the internal > implementation of such porcelain commands to refactor into stable > plumbing commands that scripters can rely on. Thank you for a decisive answer. I'll move forward with a v2 that is a doc-only change, documenting the /dev/null value as a supported mechanism for disabling hooks. Thanks, -Stolee