On 2025-04-03 at 22:38:08, Derrick Stolee via GitGitGadget wrote: > From: Derrick Stolee <stolee@xxxxxxxxx> > > Git has several hooks which are executed during certain events as long > as those hooks are enabled in the hooks directory (possibly moved from > .git/hooks via the core.hooksPath config option). These are configured > by the user, or perhaps by tooling the user has agreed to, and are not > required to operate a Git repository. > > In some situations, these hooks have poor performance and expert users > may want to skip the hooks as they don't seem to affect the current > situation. One example is a pre-commit hook that checks for certain > structures in the local changes, but expert users are likely to have > done the right thing in advance. > > I have come across users who have disabled hooks themselves either by > deleting hooks (supported, safe) or setting 'core.hooksPath' to some > bogus path (seems unsafe). The supported process is painful to swap > between the hook-enabled scenario and the hook-disabled scenario. > > To that end, add a new --no-hooks global option to allow users to > disable hooks quickly. This option is modeled similarly to the > --no-advice option in b79deeb554 (advice: add --no-advice global option, > 2024-05-03). This uses a GIT_HOOKS environment variable to communicate > to subprocesses as well as making this a backwards-compatible way for > tools to signal that they want to disable hooks. > > The critical piece is that all hooks pass through run_hooks_opt() where > a static int will evaluate the environment variable and store that the > variable is initialized for faster repeated runs. > > Signed-off-by: Derrick Stolee <stolee@xxxxxxxxx> > --- > git: add --no-hooks global option > > This is hopefully a helpful feature to more than just the experts I've > been hearing from. I think this is functionality that Jenkins wants because they've configured `core.hooksPath` to `/dev/null`, allegedly for security reasons. Of course, enabling this feature will also break Git LFS, but in a less noticeable and detectable way (currently, Git LFS will fail on attempting to install hooks with that setting of `core.hooksPath`, which is at least noticeable). I do think that in general certain types of hooks, such as pre-commit hooks, should absolutely be optional. There are lots of reasons to commit WIP data that doesn't meet whatever standard and we shouldn't impede expert users from expert workflows, even if there are many fewer reasons to do things like bypass pushing Git LFS objects (which are important for integrity). So I can see the utility of this feature but I can also see how it can break lots of things when handled poorly. Of course, we also have `git reset --hard` and there's lots of hand-wringing on Stack Overflow about having deleted important data, so we have some precedent for expert features that could break things badly. I don't otherwise have a strong opinion either way, although I'd lean slightly in favour of this series. I'd of course welcome other people's thoughts here. -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
