chore: pre-commit is the single git-hook entry point, bump hedron pin - #183
Closed
helly25 wants to merge 1 commit into
Closed
chore: pre-commit is the single git-hook entry point, bump hedron pin#183helly25 wants to merge 1 commit into
helly25 wants to merge 1 commit into
Conversation
Two related cleanups from the #182 retrospective. 1) Single git-hook entry point. Today both `pre-commit install` and `trunk actions install` write to `.git/hooks/pre-commit` and `.git/hooks/pre-push` — last installer wins, silently. Devs running both end up with one tool's hook disabled at random. Move trunk's `trunk-fmt-pre-commit` and `trunk-check-pre-push` from `actions.enabled` to `actions.disabled` in .trunk/trunk.yaml, and add a single `trunk fmt` delegate as a local hook in .pre-commit-config.yaml. pre-commit owns the git hook; devs run `pre-commit install` once and trunk's formatters fire on every commit through the delegate. CI's two jobs (`pre-commit` + `trunk`) are unchanged; both still run independently. README's dev-setup paragraph updated to match. 2) Bump hedron_compile_commands pin. `bazelmod/dev.MODULE.bazel` was pinned at `6f0f6e4f` (Apr 2024). Bump to `abb61a68` (Aug 2025) which is upstream main HEAD. The two intervening commits are pre-commit autoupdate merges only — no behavior change — but the pin should not drift further. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
helly25
added a commit
that referenced
this pull request
Aug 9, 2026
The dev-setup paragraph claimed the repo "enables `trunk-fmt-pre-commit` and `trunk-check-pre-push` so the hooks run automatically once installed". That has been false for some time: both actions are disabled in .trunk/trunk.yaml, and main.yml's "Trunk must not own git hooks" step fails the build if either is re-enabled. A dev following the README would never run `pre-commit install` and would end up with no git hooks at all. Describe what is actually there: pre-commit owns the git hook and delegates `trunk fmt` to trunk, trunk's own hook actions stay disabled so the two cannot fight over .git/hooks, and CI runs pre-commit, trunk check and clang-tidy as separate jobs. clang-tidy is one of the pre-commit hooks too - it moved there from trunk, which pinned a version too old to parse this code - opt-in for now and automatic once the finding sweep lands. STYLE_CPP.md has the details. The paragraph is taken from #183, which proposed it before the CI guard and the clang-tidy job existed; the rest of that PR is superseded. Signed-off-by: helly25 <6420169+helly25@users.noreply.github.com>
helly25
added a commit
that referenced
this pull request
Aug 9, 2026
The dev-setup paragraph claimed the repo "enables `trunk-fmt-pre-commit` and `trunk-check-pre-push` so the hooks run automatically once installed". That has been false for some time: both actions are disabled in .trunk/trunk.yaml, and main.yml's "Trunk must not own git hooks" step fails the build if either is re-enabled. A dev following the README would never run `pre-commit install` and would end up with no git hooks at all. Describe what is actually there: pre-commit owns the git hook and delegates `trunk fmt` to trunk, trunk's own hook actions stay disabled so the two cannot fight over .git/hooks, and CI runs pre-commit, trunk check and clang-tidy as separate jobs. clang-tidy is one of the pre-commit hooks too - it moved there from trunk, which pinned a version too old to parse this code - opt-in for now and automatic once the finding sweep lands. STYLE_CPP.md has the details. The paragraph is taken from #183, which proposed it before the CI guard and the clang-tidy job existed; the rest of that PR is superseded. Signed-off-by: helly25 <6420169+helly25@users.noreply.github.com>
Owner
Author
|
Superseded — both halves are obsolete, and the one surviving piece has moved to #279. 1. Single git-hook entry point — already done, and more thoroughly than proposed here. 2. Extractor pin bump — now actively wrong. This bumps 3. The README paragraph was still valuable — it was the only part describing reality, since the old text still claimed the trunk hooks are enabled. It has been lifted into #279, extended to mention the Thanks — the hook-ownership analysis here is what the current design ended up implementing. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two related cleanups from the #182 retrospective.
1. Single git-hook entry point
Today both
pre-commit installandtrunk actions installwrite to.git/hooks/pre-commitand.git/hooks/pre-push— last installer wins, silently. Devs running both end up with one tool's hook disabled at random.Resolution:
trunk-fmt-pre-commitandtrunk-check-pre-pushfromactions.enabledtoactions.disabledin.trunk/trunk.yaml.trunk fmtdelegate as alocalhook in.pre-commit-config.yaml.pre-commit installonce and trunk's formatters fire on every commit through the delegate.pre-commit+trunk) are unchanged; both still run independently.README's dev-setup paragraph updated to match.
2. Bump
hedron_compile_commandspinbazelmod/dev.MODULE.bazelwas pinned at6f0f6e4f(Apr 2024). Bump toabb61a68(Aug 2025), which is current upstreammainHEAD. The two intervening commits are pre-commit autoupdate merges only — no behavior change — but the pin should not drift further.Test plan
pre-commit installonce locally;git committriggerstrunk fmtvia the new local hook without anytrunk actions installstep.🤖 Generated with Claude Code