Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pre-commit hooks are broken

jyn.dev

Post reply on HN
Print view View original

21–30 of 178 posts

Re: Pre-commit hooks are broken

#21

Post by Ferret7446 »

nine_k wrote: post #7

A bit less enraged: pre-commit hooks should be pure functions. They must not mutate the files being committed. At best, they should generate a report. At worst, they could reject a commit (e.g. if it contains a private key file included by mistake).

In my experience pre-commit hooks are most often used to generate a starting commit message.

To put it more bluntly, pre-commit hooks are pre-commit hooks, exactly what it says on the tin. Not linting hooks or checking hooks or content filters. Depending on what exactly you want to do, they may or may not be the best tool for the job.

To put it even more bluntly, if you are trying to enforce proper formatting, pre-commit hooks are absolutely the wrong tool for the job, as hooks are trivially bypassable, and not shared when cloning a repo, by design.

Re: Pre-commit hooks are broken

#23

Post by hbogert »

wolfi1 wrote: post #22

why do people rebase so often? shouldn't it be excluded from the usual workflows as you are losing commit history as well?

why would you lose commit history? You are just picking up a set of commits and reapplying them. Of course you can use rebase for more things, but rebase does not equal losing commit history.

Re: Pre-commit hooks are broken

#24

Post by hbogert »

tkzed49 wrote: post #4

Thank you. I don't need to "fix" a commit before it ends up on a remote branch. Sometimes I expect a commit to pass checks and sometimes I don't. Frankly, don't even run pre-push hooks. Just run the checks in CI when I push. You'd better be doing that anyway before I'm allowed to push to a production branch, so stop breaking my git workflows and save me the time of running duplicate checks locally. Also, if most deve…

I don't want roundtrips to my CI which easily takes a minute and pushes me to look at yet another window. Pre-commit hooks save me so much time.

Re: Pre-commit hooks are broken

#25

Post by hbogert »

normie3000 wrote: post #17
thomashabets2 wrote: post #9

Earlier quoted context omitted.

Is that the difference between forced pre commits vs opt in? I don't want to commit something that doesn't build. If nothing else it makes future bisects annoying. But if I intend to squash and merge, then who cares about intermediate state.

> I don't want to commit something that doesn't build. This is a really interesting perspective. Personally I commit code that will fail the build multiple times per day. I only care that something builds at the point it gets merged to master.

so basically, not adhering to atomic commits. That's fine if it's a deliberate choice, but some people like me think commits should stand on their own.

(i'm assuming your are not squashing when merging, else it's pretty much the same workflow)

Re: Pre-commit hooks are broken

#26

Post by mcny »

wolfi1 wrote: post #22

why do people rebase so often? shouldn't it be excluded from the usual workflows as you are losing commit history as well?

I write really poopy commit messages. Think "WIP" type nonsense. I branch off of the trunk, even my branch name is poopy like

feature/{first initial} {last initial} DONOTMERGE {yyyy-MM-dd-hh-mm-ss}

Yes, the branch name literally says do not merge.

I commit anything and everything. Build fails? I still commit. If there is a stopping point and I feel like I might want to come back to this point, I commit.

I am violently against any pre commit hook that runs on all branches. What I do on my machine on my personal branch is none of your business.

I create new branches early and often. I take upstream changes as they land on the trunk.

Anyway, this long winded tale was to explain why I rebase. My commits aren't worth anything more than stopping points.

At the end, I create a nice branch name and there is usually only one commit before code review.

Re: Pre-commit hooks are broken

#29

Post by a_t48 »

Running on the working tree is mostly okay - just `exit 1` if changes were made and allow the user to stage+commit new changes. It isn't perfect but it doesn't require checking out a new tree.

Re: Pre-commit hooks are broken

#30

Post by rkomorn »

mcny wrote: post #26
wolfi1 wrote: post #22

why do people rebase so often? shouldn't it be excluded from the usual workflows as you are losing commit history as well?

I write really poopy commit messages. Think "WIP" type nonsense. I branch off of the trunk, even my branch name is poopy like feature/{first initial} {last initial} DONOTMERGE {yyyy-MM-dd-hh-mm-ss} Yes, the branch name literally says do not merge. I commit anything and everything. Build fails? I still commit. If there is a stopping point and I feel like I might want to come back to this point, I commit. I am violentl…

Isn't your tale more about squashing than rebasing?
Post reply on HN