Welcome to the 123rd edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.
This edition covers what happened during the months of April and May 2025.
[GSoC] Welcoming our 2025 contributors and thanking our applicants
The Git project was accepted in the Google Summer of Code (GSoC) this year again, and 3 applicants were selected:
Meet Soni will work on the “Consolidate ref-related functionality into git-refs” project mentored by Patrick Steinhardt and Jialuo She. See Meet’s blog and repository for more.
Lucas Seiki Oshiro will work on the “Machine-Readable Repository Information Query Tool” project mentored by Karthik Nayak and Patrick Steinhardt. See Lucas’s blog and repository for more.
Ayush Chandekar will work on the “Refactoring in order to reduce Git’s global state” project mentored by Christian Couder and Ghanshyam Thakkar. See Ayush’s blog and repository for more.
[PATCH] git: add --no-hooks global option
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 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 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.
In the meantime, Lucas Seiki Oshiro 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,
Stolee just updated the documentation of the core.hooksPath
configuration option, adding the following small paragraph:
You can also disable all hooks entirely by setting
core.hooksPathto/dev/null. This is usually only advisable for expert users and on a per-command basis using configuration parameters of the formgit -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.
Light reading
jj) is an experimental Git-compatible DVCS,
first mentioned in Git Rev News Edition #85.git completion for the ! alias.expand tool (part of the coreutils),
by Eevee on Fuzzy Notepad blog (2016).git-upload-pack for a simpler CI integration,
on how Screenshotbot can now extract commit graph data from remote repositories
(assuming one has SSH access to their Git repositories),
by Arnold Noronha on Screenshotbot Blog.url.<base>.insteadOf.Git tools and sites
This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Kaartic Sivaraam <kaartic.sivaraam@gmail.com>.