{"slug": "pre-commit", "name": "pre-commit", "category": "other", "category_name": "Other software", "description": "", "recommenders": 3, "commenters": 4, "warners": 0, "score": 2.704, "rising": -0.98, "first": "2025-11-18", "latest": "2026-02-15", "why": "It's a really good way to share check definitions between local development and CI", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 3, "neutral": 1, "compare": 0, "warn": 0}, "spark": [1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "It's a really good way to share check definitions between local development and CI", "icon": true, "domain": "pre-commit.com", "github_repo": null, "official_url": "https://pre-commit.com", "pricing": "", "aliases": ["pre-commit"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 742653920, "item_id": 46415870, "url": "https://news.ycombinator.com/item?id=46415870", "by": "souperdeluxe", "date": "2025-12-28", "stance": "recommend", "quote": "for small teams, I love pre-commit and trunk-based development.", "excerpt": "Without pre-commit you should squash on merge. That way main is atomic. But squashing loses granularity. A single merge commit might both refactor a function and implement a feature. You could split it into two pull requests, but maybe the feature depends on the refactor. Now your feature branch needs to cherry pick from the refactor branch. What if the refactor branch makes further changes prior to being merged? Now", "context": "small team", "use_case": "git hooks for small teams", "switched_from": "", "story": "Pre-commit hooks are fundamentally broken"}, {"id": 742467456, "item_id": 46404216, "url": "https://news.ycombinator.com/item?id=46404216", "by": "andrewaylett", "date": "2025-12-27", "stance": "recommend", "quote": "It's a really good way to share check definitions between local development and CI", "excerpt": "You shouldn't be relying on hooks to maintain the integrity of your codebase, and I'm not seeing anything here that makes me want to avoid `pre-commit` (or, more literally, the https://pre-commit.com/ tool). CI must be the source of truth for whether a commit is acceptable. If you're using `pre-commit` the tool, not merely the hook, you can also use something like https://github.com/andrewaylett/pre-commit-action to ", "context": "", "use_case": "sharing checks between local and CI", "switched_from": "", "story": "Pre-commit hooks are fundamentally broken"}, {"id": 735621024, "item_id": 45976314, "url": "https://news.ycombinator.com/item?id=45976314", "by": "rsyring", "date": "2025-11-18", "stance": "recommend", "quote": "just run pre-commit on all files in CI", "excerpt": "And...that's exactly why you might want to use pre-commit. Set it up to run locally, treating the dev environment check as the first class citizen, then just run pre-commit on all files in CI. We use that pattern for almost all our projects. Example: https://github.com/level12/coppy", "context": "", "use_case": "local and CI checks", "switched_from": "", "story": "Better pre-commit, re-engineered in Rust"}]}], "caveats": [], "who": [{"by": "benrutter", "context": "uses monorepos daily", "url": "https://news.ycombinator.com/item?id=47022628", "date": "2026-02-15"}, {"by": "souperdeluxe", "context": "small team", "url": "https://news.ycombinator.com/item?id=46415870", "date": "2025-12-28"}], "tags": [], "use_cases": ["monorepo hooks", "git hooks for small teams", "sharing checks between local and ci", "local and ci checks"], "compared": [{"slug": "git", "name": "Git", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=46398906", "title": "Pre-commit hooks are fundamentally broken", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=47022238", "title": "Git is a file system. We need a database for the code", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=45931273", "title": "Better pre-commit, re-engineered in Rust", "mentions": 1}], "sentiment_by_month": {"2025-11": {"recommend": 1}, "2025-12": {"recommend": 2}, "2026-01": {}, "2026-02": {"neutral": 1}, "2026-03": {}, "2026-04": {}, "2026-05": {}, "2026-06": {}, "2026-07": {}, "2026-08": {}, "2026-09": {}, "2026-10": {}}, "quotes": [{"id": 752362049, "item_id": 47022628, "url": "https://news.ycombinator.com/item?id=47022628", "by": "benrutter", "date": "2026-02-15", "stance": "neutral", "quote": "tools like precommit can get a bit messy", "excerpt": "> The monorepo problem: git has difficulty dividing the codebase into modules and joining them back Can anyone explain this one? I use monorepos everyday and although tools like precommit can get a bit messy, I've never found git itself to be the issue?", "context": "uses monorepos daily", "use_case": "monorepo hooks", "switched_from": "", "story": "Git is a file system. We need a database for the code"}, {"id": 742653920, "item_id": 46415870, "url": "https://news.ycombinator.com/item?id=46415870", "by": "souperdeluxe", "date": "2025-12-28", "stance": "recommend", "quote": "for small teams, I love pre-commit and trunk-based development.", "excerpt": "Without pre-commit you should squash on merge. That way main is atomic. But squashing loses granularity. A single merge commit might both refactor a function and implement a feature. You could split it into two pull requests, but maybe the feature depends on the refactor. Now your feature branch needs to cherry pick from the refactor branch. What if the refactor branch makes further changes prior to being merged? Now", "context": "small team", "use_case": "git hooks for small teams", "switched_from": "", "story": "Pre-commit hooks are fundamentally broken"}, {"id": 742467456, "item_id": 46404216, "url": "https://news.ycombinator.com/item?id=46404216", "by": "andrewaylett", "date": "2025-12-27", "stance": "recommend", "quote": "It's a really good way to share check definitions between local development and CI", "excerpt": "You shouldn't be relying on hooks to maintain the integrity of your codebase, and I'm not seeing anything here that makes me want to avoid `pre-commit` (or, more literally, the https://pre-commit.com/ tool). CI must be the source of truth for whether a commit is acceptable. If you're using `pre-commit` the tool, not merely the hook, you can also use something like https://github.com/andrewaylett/pre-commit-action to ", "context": "", "use_case": "sharing checks between local and CI", "switched_from": "", "story": "Pre-commit hooks are fundamentally broken"}, {"id": 735621024, "item_id": 45976314, "url": "https://news.ycombinator.com/item?id=45976314", "by": "rsyring", "date": "2025-11-18", "stance": "recommend", "quote": "just run pre-commit on all files in CI", "excerpt": "And...that's exactly why you might want to use pre-commit. Set it up to run locally, treating the dev environment check as the first class citizen, then just run pre-commit on all files in CI. We use that pattern for almost all our projects. Example: https://github.com/level12/coppy", "context": "", "use_case": "local and CI checks", "switched_from": "", "story": "Better pre-commit, re-engineered in Rust"}]}