On 4/3/2025 6:55 PM, brian m. carlson wrote: > On 2025-04-03 at 22:38:08, Derrick Stolee via GitGitGadget wrote: >> From: Derrick Stolee <stolee@xxxxxxxxx> >> 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. >> 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 agree that some hooks are necessary for certain repositories to keep their data consistent. Another example is the pre- and post-command hooks that are in the microsoft/git fork that are necessary to avoid issues with the virtualization layer of VFS for Git. If a user disables those hooks during a command that changes the index, then they are going to have a bad time. But maybe they want to disable hooks because all they need is a 'git rev-parse HEAD' or similarly read-only operation. > 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). My intention is definitely more on the side of these optional hooks. > 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. Thank you for chiming in! I look forward to other thoughts and whetherthe warning in the docs should be strengthened. Thanks, -Stolee
