Hacker News Reader

Comment by ninkendo | Hacker News Reader

I'm not entirely sure I want to sit through a 10 minute linting process every time I do a quick `git add -A && git commit -m WIP` locally. Why does it need to be a pre-commit hook instead of a simple PR check? PR checks obviously need to be done anyway.

View on HN

10 minutes?

A strategy I have used is: - only lint the files that have changed - only apply lint rules that can be auto-fixed

This usually takes less than a second (short enough that you can't really tell the difference) and the developer doesn't have to do anything .

> 10 minutes?

Yes. I work in a codebase that's 30GB checked out. It takes a long time to run our automated checks. That's why they happen on the server, when I make a pull request.

The upshot is the same: it doesn't go to master until checks pass. But who gives a shit about what I'm committing locally? I reserve the right to save my work even if things aren't compiling. You (my teammate) won't see it anyway, it's all locally on my machine. Why do you care?

    git commit -m WIP

I hope you're rebasing that terrible commit message away before pushing this remotely.

I hope the pre-commit hook validates the commit message follows the correct format which links the work to the correct ticket number and if you left off the ticket number inserts it for you based off the branch name etc.

No. No. NO.

My commits locally are my business, and 100000% orthogonal to what YOU (my teammate) will see when I'm ready to make a PR. Because I rebase, I reword commits, and I squash things as necessary before I submit a pull request.

The horrible conflation of commits (what I do when I want to save my work) and pull/merge requests (what I do when I want to integrate my work into the repo that everyone sees) is the very reason why git was created to begin with. If you want centralized version control where "commit" means "everyone sees it and it has to pass checks", use SVN. Seriously, get away from my tools.

Yeah, but none of that would be affected right? If you don't prepend the ticket number, it'll do it for you. That gives the entire team a guarantee all the work is traceable. It's a tool that serves the whole team, not just you.

Why should this be done at pre-commit time? And what automated system will be able to guess a ticket number based only on what's in a commit?

I'm all for validation that all commits must have some metadata/ticket numbers attached... at the time it is merged into master. Not on my local machine.

I probably did `git add -A && git commit -m WIP` at least 7 or 8 times today alone. But all my commits that made it into a PR were squashed, divided up logically, and renamed before they went in.

I'm trying to imagine a system where some automated thing prepends "TICKET#123 WIP" before every commit I make, locally, even if they're all getting thrown away before I squash/rebase/reword my commits. What's the point?

Your local pre-commit hooks are separate to your remote pre-commit hooks.

There's no such thing as a remote pre-commit hook. Do you mean a pre-push hook? That's a different story, but even then what you really want is to just deny access to shared branches, except to your CI system, which will run your checks before allowing you to merge.

GitHub/GitLab/BitBucket/etc all have this kind of system, it's not new or interesting.

Reply on news.ycombinator.com