Pre-commit hooks are broken

Original Article ↗ Hacker News Discussion ↗

Role of hooks vs CI

  • Strong consensus that hooks are not enforceable or reliable for policy; CI must be the source of truth.
  • Hooks are compared to client-side validation; CI to server-side validation.
  • Many argue hooks should be opt‑in productivity tools to reduce CI churn, not gatekeepers for correctness.

Impact on developer workflows

  • Mandatory or auto-installed hooks are widely reported as frustrating, especially when slow, flaky, or stateful.
  • Hooks often break workflows involving:
    • WIP commits, frequent small “checkpoint” commits.
    • Interactive rebases, merges, and partial staging (git add -p).
    • Non-standard or power-user workflows, or less-technical users (e.g., game studio artists/designers).
  • Because --no-verify and local hook directories are trivial workarounds, strict hooks tend to be bypassed, undermining their purpose.

What hooks are appropriate

  • Many recommend only fast, deterministic hooks that don’t depend on network, external services, or complex state.
  • Several argue hooks should be pure: no mutating the working tree, ideally just reporting issues or rejecting commits.
  • Secret detection and large-file checks are cited as rare cases where pre-commit/pre-push is valuable because CI is “too late.”
  • Formatting and lint enforcement are seen as better suited to:
    • Editors/IDEs and local scripts.
    • Pre-push hooks or CI pipelines, not pre-commit.

History rewriting and rebasing

  • Debate over whether branches are personal and mutable until PRs vs. becoming “shared” once a PR is open.
  • Some teams treat working/PR branches as mutable and squash to a single commit; others value atomic commits that always build, for bisecting and comprehension.
  • Strong disagreements over heavy rebasing vs. merge-based workflows and linear main branches vs. preserving merge history.

Tooling and alternative approaches

  • Mentioned tools/workflows: pre-commit framework, lefthook, git filters, git-absorb, git rebase -x, JJ/jujutsu (jj fix, planned jj run), git worktrees.
  • Some say frameworks mitigate common hook pitfalls; others note they can’t fix bad hook design or fundamental UX issues.
  • Several prefer explicit local scripts or editor integration over automatic hooks for formatting/linting.

Philosophy of commit history

  • Split between:
    • Treating commits as disposable local checkpoints, with squash at merge.
    • Treating commit history as a structured narrative aiding review, debugging, and long-term maintenance.
  • Tension between individual productivity and shared-team readability/maintainability is a recurring theme.