rn-123: add --no-hooks article

Author: chriscool

rev_news/drafts/edition-123.md

@@ -21,9 +21,109 @@ This edition covers what happened during the months of April 2025 and May 2025.
 ### General
 -->
 
-<!---
+
 ### Reviews
--->
+
+* [[PATCH] git: add --no-hooks global option](https://lore.kernel.org/git/pull.1899.git.1743719888430.gitgitgadget@gmail.com/)
+
+  Derrick Stolee, who prefers to be called just Stolee, sent a patch
+  to the mailing list that added a new `--no-hooks` global option, and
+  an equivalent `GIT_HOOKS` environment variable, to Git. The goal was
+  to allow users to disable all Git hooks during command execution.
+
+  This could be useful for expert users who would want to bypass
+  pre-commit hooks when they have poor performance or perform useless
+  checks.
+
+  Switching between enabled and disabled hooks and other workarounds,
+  like setting `core.hooksPath` to a "bogus path" did not look
+  convenient and very safe.
+
+  brian m. carlson, who spell their name using only lowercase letters,
+  replied to Stolee acknowledging the need for this functionality as
+  some Jenkins users already set `core.hooksPath` to `/dev/null` for
+  security reasons. They warned that disabling hooks could break
+  [Git LFS](https://git-lfs.com/) in a way that is "less noticeable
+  and detectable" than the current `/dev/null` approach.
+
+  They agreed that certain hooks like pre-commit hooks should be
+  optional, for example to make it easy to commit some
+  work-in-progress that doesn't meet standards, but saw fewer reasons
+  to bypass hooks that could be important for repository integrity.
+
+  Stolee agreed that some hooks are important for integrity, but said
+  his intention was on the side of optional hooks.
+
+  Phillip Wood also replied to Stolee's initial email noting that
+  there is already `git commit --no-verify` which bypasses the
+  pre-commit and commit-msg hooks. He argued that hooks so slow that
+  users want to bypass them are self-defeating and that the solution
+  should be to fix the hook's performance rather than make it easier
+  to skip. About setting `core.hooksPath` to `/dev/null`, he asked why
+  it could be unsafe. In general he said he wasn't convinced that
+  `--no-hooks` was a good idea, and later asked for "a clearer
+  motivation" to better understand its usefulness.
+
+  Stolee agreed that setting `core.hooksPath` to `/dev/null` was safe,
+  and said he had forgotten that could be used instead of a bogus
+  path.
+
+  Junio Hamano, the Git maintainer, then replied to Phillip thanking
+  him for pushing back on the idea, and saying that there should be a
+  "compelling reason" to justify applying a change.
+
+  Also instead of implementing options to disable hooks or
+  configuration in some user facing "porcelain" commands, Junio
+  advocated for cleaning up and refactoring these commands into new
+  stable "plumbing" commands designed to be easily used in scripts.
+
+  Lucas Seiki Oshiro in the meantime replied to Phillip. Lucas had
+  noticed that using `/dev/null` to disable hooks wasn't mentioned in
+  the documentation of `core.hooksPath` even though it was tested in a
+  test script. He asked if Stolee's patch should therefore be turned
+  into a documentation patch.
+
+  brian agreed with Lucas that documenting how to disable hooks was a
+  good idea even if the `--no-hooks` option wasn't implemented.
+
+  D. Ben Knoble also replied to Stolee's initial patch. He supported
+  the addition of the `--no-hooks` option, sharing his own
+  frustrations with poorly performing or difficult-to-manage hooks. He
+  described how a tool re-enables hooks after every `npm install`
+  leading him to overuse `--no-verify`, which he considered a worse
+  situation. He believed there should be a safe and sane way to
+  disable optional client-side hooks and felt that a `--no-hooks`
+  option would be useful, potentially encouraging better practices
+  like moving certain checks to server-side hooks.
+
+  Stolee then replied to Junio thanking him for deciding about this
+  and saying he would follow up with a version 2 of his patch that
+  would only document that setting `core.hooksPath` to `/dev/null` was
+  the supported mechanism to disable hooks.
+
+  In [the version 2 of his patch](https://lore.kernel.org/git/pull.1899.v2.git.1744818135435.gitgitgadget@gmail.com/)
+  indeed Stolee only updated the documentation of the `core.hooksPath`
+  configuration option, adding the following small paragraph:
+
+  > 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 ...`.
+
+  Lucas replied to that new patch. He suggested rewording the
+  documentation to focus on non-expert users rather than
+  experts. Stolee disagreed, explaining he intentionally targeted
+  expert users as a "there be dragons here" warning about the risks of
+  disabling hooks.
+
+  brian supported Stolee's approach, agreeing that this feature should
+  be presented as expert-only due to the potential for data loss (like
+  missing Git LFS uploads). He appreciated Stolee's gracious pivot
+  from code changes to documentation.
+
+  Junio also thanked Stolee for gracefully changing direction and
+  ensuring no loose ends were left after abandoning the original
+  approach.
 
 <!---
 ### Support