Re: [PATCH] git: add --no-hooks global option

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 16, 2025, 14:28 UTC
Message-ID: <xmqqh62oi3k7.fsf@gitster.g>
In-Reply-To: <a5632198-9e04-4302-a3c9-1cbf0f0cad65@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 16 quoted lines

>> 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.