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.
