Hook Managers

## Why .git/hooks is not shared Git looks for hooks in the repository's hooks directory, which is `.git/hooks` in an ordinary clone. Everything under `.git` is repository *metadata* — the object database, refs, the index, config — not repository *content*. Only content that has been added to a tree and committed is transferred by `git clone`, `git fetch` or `git push`. Hook scripts placed in `.git/hooks` are therefore invisible to every other clone. What a new clone actually gets is a copy of Git's template directory: a set of example scripts named `pre-commit.sample`, `commit-msg.sample`, and so on. The `.sample` suffix means Git will not execute them, because Git only runs a hook file whose name matches the hook exactly and which is executable. ## core.hooksPath Recent Git supports the `core.hooksPath` configuration key, which overrides the hooks directory. Set it once per clone: `git config core.hooksPath .githooks` Now the hook scripts can be ordinary tracked files under `.githooks/`, reviewed in pull requests and updated for everyone by a normal commit. Two details matter. First, `core.hooksPath` **replaces** `.git/hooks` — it does not add a second search location, so any hook still sitting in `.git/hooks` silently stops running. Second, the executable bit is tracked by Git (mode `100755` versus `100644`), so committing the scripts with the executable bit set is what makes them runnable on checkout. You can confirm what Git will actually use with `git rev-parse --git-path hooks`, which prints the effective hooks directory after config is applied, or `git config --get core.hooksPath`. ## The install step, and why it cannot be avoided `core.hooksPath` is a config value, and configuration lives in `.git/config`, which is not transferred by a clone either. So there is always a one-time step per clone. This is deliberate. If a repository could ship configuration that made Git execute a script, then merely cloning an untrusted repository would be arbitrary code execution. Git keeps the decision to enable hooks on the machine that runs them. Teams automate the step rather than remove it: a documented `make setup`, a bootstrap script, or a package-manager lifecycle script such as npm's `prepare`, which runs after a normal dependency install. That is the trick most JavaScript hook managers use. ## What the managers add - **husky** keeps hooks in a tracked directory (conventionally `.husky/`) and points `core.hooksPath` at it; its install is normally wired to the `prepare` lifecycle script so a dependency install enables hooks. - **lefthook** reads a tracked `lefthook.yml` describing which commands run for which hook, and its install command writes the hook entries; it can run the listed commands in parallel. - **pre-commit** (the Python framework) reads `.pre-commit-config.yaml`, where each hook is pinned to a revision of the tool's repository and run in an isolated environment; its install writes a dispatch script into `.git/hooks`, which is why it conflicts with a manager that sets `core.hooksPath`. All three solve the same two problems: make the hook definitions versioned content, and make enabling them one command. ## Failure modes to expect - A developer clones and never runs the install step. Nothing warns them; the hooks are simply absent, and their commits skip every local check. - Two managers in one repository. The one that sets `core.hooksPath` wins and the one that writes into `.git/hooks` is ignored entirely — a confusing silent failure. - Automated or CI clones frequently install dependencies with scripts disabled, or install production dependencies only, so lifecycle-script-based hook installation does not happen there. That is usually the desired outcome, not a bug, but it means the hooks are not a guarantee anywhere. - Someone copies a script into `.git/hooks` for a quick fix while `core.hooksPath` is set, and cannot work out why it never runs. The upshot: versioned hooks plus one explicit enable step give you a shared, reviewable local check, but never an enforced one.