On 4/16/2025 10:28 AM, Junio C Hamano wrote: > Phillip Wood <phillip.wood123@xxxxxxxxx> 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
