From: Derrick Stolee <stolee@gmail•com>
To: Junio C Hamano <gitster@pobox•com>,
Phillip Wood <phillip.wood123@gmail•com>
Cc: phillip.wood@dunelm•org.uk,
Derrick Stolee via GitGitGadget <gitgitgadget@gmail•com>,
git@vger•kernel.org, james@jamesliu•io,
"brian m. carlson" <sandals@crustytoothpaste•net>
Subject: Re: [PATCH] git: add --no-hooks global option
Date: Wed, 16 Apr 2025 11:30:51 -0400 [thread overview]
Message-ID: <baa62f25-faa4-418f-8100-0a75cb803267@gmail.com> (raw)
In-Reply-To: <xmqqh62oi3k7.fsf@gitster.g>
On 4/16/2025 10:28 AM, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail•com> 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
next prev parent reply other threads:[~2025-04-16 15:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-03 22:38 [PATCH] git: add --no-hooks global option Derrick Stolee via GitGitGadget
2025-04-03 22:55 ` brian m. carlson
2025-04-04 0:40 ` Derrick Stolee
2025-04-04 14:15 ` Phillip Wood
2025-04-14 10:59 ` Derrick Stolee
2025-04-16 10:29 ` Phillip Wood
2025-04-16 14:28 ` Junio C Hamano
2025-04-16 15:30 ` Derrick Stolee [this message]
2025-04-14 15:25 ` Lucas Seiki Oshiro
2025-04-14 21:05 ` brian m. carlson
2025-04-11 18:53 ` D. Ben Knoble
2025-04-16 15:42 ` [PATCH v2] docs: document core.hooksPath=/dev/null Derrick Stolee via GitGitGadget
2025-04-16 16:53 ` Lucas Seiki Oshiro
2025-04-17 0:25 ` Derrick Stolee
2025-04-17 0:39 ` brian m. carlson
2025-04-17 3:42 ` Junio C Hamano
2025-04-17 16:02 ` Lucas Seiki Oshiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=baa62f25-faa4-418f-8100-0a75cb803267@gmail.com \
--to=stolee@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=gitster@pobox$(echo .)com \
--cc=james@jamesliu$(echo .)io \
--cc=phillip.wood123@gmail$(echo .)com \
--cc=phillip.wood@dunelm$(echo .)org.uk \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox