| Message ID | pull.1899.v2.git.1744818135435.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 1b2eee94f120969690d772af5a14f681f7d875a7 |
| Headers | show |
| Series | [v2] docs: document core.hooksPath=/dev/null | expand |
Hi! > +You can also disable all hooks entirely by setting `core.hooksPath` > +to `/dev/null`. Personally I think it would be better to focus on the non-expert user, something like: """ You can also use this variable to disable all hooks entirely by setting it to `/dev/null`. For non-expert users in a per-command basis it is advisable to use configuration parameters of the form `git -c core.hooksPath=/dev/null ...`. """
On 4/16/2025 12:53 PM, Lucas Seiki Oshiro wrote: > Hi! > >> +You can also disable all hooks entirely by setting `core.hooksPath` >> +to `/dev/null`. > > Personally I think it would be better to focus on the non-expert user, I absolutely want this to be targeted for expert users, so users self- select themselves into the risk of what happens when disabling hooks. This is a "there be dragons here" kind of warning, implying that you better know what you're doing if you are messing with hook paths. Thanks, -Stolee
On 2025-04-17 at 00:25:28, Derrick Stolee wrote: > On 4/16/2025 12:53 PM, Lucas Seiki Oshiro wrote: > > Hi! > > > >> +You can also disable all hooks entirely by setting `core.hooksPath` > >> +to `/dev/null`. > > > > Personally I think it would be better to focus on the non-expert user, > > I absolutely want this to be targeted for expert users, so users self- > select themselves into the risk of what happens when disabling hooks. > This is a "there be dragons here" kind of warning, implying that you > better know what you're doing if you are messing with hook paths. Yes, I think that's the right choice. As we've established elsewhere, it's easy to break things or cause data loss (e.g., by not pushing Git LFS objects) by disabling hooks and the user should be confident of what they're doing before doing so. That being said, I agree that in the general case we should make our documentation accessible to non-expert users because nobody is born knowing how to use Git and that will benefit the most people. This just happens to be an exception. I thought the text in the patch looked good to me. I appreciate you graciously pivoting approaches and documenting this, both for the benefit of users and as an approach to help make sure we don't break this functionality.
"brian m. carlson" <sandals@crustytoothpaste.net> writes: > I thought the text in the patch looked good to me. I appreciate you > graciously pivoting approaches and documenting this, both for the > benefit of users and as an approach to help make sure we don't break > this functionality. Thanks, all. I too appreciate that Derrick left no loose ends untied after changing direction.
> This is a "there be dragons here" kind of warning, implying that you > better know what you're doing if you are messing with hook paths. Fair, I understand your point. The paragraph itself looks very clear to me! Thanks!
diff --git a/Documentation/config/core.adoc b/Documentation/config/core.adoc index 8f6d8e77541..9fde1ab63a7 100644 --- a/Documentation/config/core.adoc +++ b/Documentation/config/core.adoc @@ -512,6 +512,11 @@ centrally configure your Git hooks instead of configuring them on a per-repository basis, or as a more flexible and centralized alternative to having an `init.templateDir` where you've changed default hooks. ++ +You can also disable all hooks entirely by setting `core.hooksPath` +to `/dev/null`. This is usually only advisable for expert users and +on a per-command basis using configuration parameters of the form +`git -c core.hooksPath=/dev/null ...`. core.editor:: Commands such as `commit` and `tag` that let you edit