[nrclark]

This was a really interesting read. I'd highly recommend it for anybody who's setting up (or currently maintains) a pre-commit workflow for their developers.

I want to add one other note: in any large organization, some developers will use tools in ways nobody can predict. This includes Git. Don't try to force any particular workflow, including mandatory or automatically-enabled hooks.

Instead, put what you want in an optional pre-push hook and also put it into an early CI/CD step for your pull request checker. You'll get the same end result but your fussiest developers will be happier.

[eru]

> This includes Git. Don't try to force any particular workflow, including mandatory or automatically-enabled hooks.

And with git, you can even make anything that happens on the dev machines mandatory.

Anything you want to be mandatory needs to go into your CI. Pre-commit and pre-push hooks are just there to lower CI churn, not to guarantee anything.

(With the exception of people accidentally pushing secrets. The CI is too late for that, and a pre-push hook is a good idea.)

[darkwater]

A good analogy is: git hooks are client-side validation; CI is server-side validation, aka the only validation you can trust.

[normie3000]

> with git, you can even make anything that happens on the dev machines mandatory

s/can/can't?

[beezlewax]

You can run git commit with a --no-verify flag to skip these hooks

[Mic92]

I can second that. If there are multiple commits: https://github.com/tummychow/git-absorb is handy to add formatting changes into the right commit after commits already happened.

[oxryly1]

It looks like git absorb rewrites history. Doesn’t that break your previously pushed branch?

[mcv]

There's a weird thing happening on my current project. Sometimes I merge main into my branch and it fails. What fails is the pre-commit hook on the merge commit. Changes in main fail the linting checks in the pre-commit hook. But they still ended up in main, somehow. So the checks on the PR are apparently not as strict as the checks on the pre-commit hook. As a result, many developers have gotten used to committing with `--no-verify`, at which point, what is even the point of a pre-commit hook?

And sometimes I just want to commit work in progress so I can more easily backtrack my changes. These checks are better on pre-push, and definitely should be on the PR pipeline, otherwise they can and will be skipped.

Anyway, thanks for giving me some ammo to make this case.

[baobun]

For the sake of argument, let's say you have a check that caps the number of lines per file and that both you and main added lines in the same file. It's not too weird if that check fails only after merge, right?

One benign example of something that can break after merge even if each branch is individually passing pre-merge. In less benign cases it will your branch merged to main and actual bugs in the code.

One reason to not allow "unclean merges" and enforced incoming branches to be rebased up-to-date to be mergable to the main branch.

You probably want to run the checks on each commit to main in CI and not rely on them being consistently run by contributors.

You do you but I find rebasing my branch on main instead of merging makes me scratch mybhead way less.

[QuercusMax]

Your hook really shouldn't be running on the merge commit unless you have conflicts in your merge.

[r2vcap]

Why not take the best of both worlds? Use pre-commit hooks for client-side validation, and run the same checks in CI as well. I’ve been using this setup for years without any issues.

One key requirement in my setup is that every hook is hermetic and idempotent. I don’t use Rust in production, so I can’t comment on it in depth, but for most other languages—from clang-format to swift-format—I always download precompiled binaries from trusted sources (for example, the team’s S3 storage). This ensures that the tools run in a controlled environment and consistently produce the same results.

[andrewaylett]

Case in point: https://www.jj-vcs.dev/

[PunchyHamster]

> I want to add one other note: in any large organization, some developers will use tools in ways nobody can predict. This includes Git. Don't try to force any particular workflow, including mandatory or automatically-enabled hooks.

you will save your org a lot of pain if you do force it, same as when you do force a formatting style rather than letting anyone do what they please.

You can discuss to change it if some parts don't work but consistency lowers the failures, every time.

[dxdm]

Enforcement should live in CI. Into people's dev environments, you put opt-in "enablement" that makes work easier in most cases, and gets out of the way otherwise.

[tomjakubowski]

It's a good thing you can't force it, because `git commit -n` exists. (And besides, management of the `.git/hooks` directory is done locally. You can always just wipe that directory of any noxious hooks.)

I can accept (but still often skip, with `git push -n`) a time-consuming pre-push hook, but a time-consuming and flaky pre-commit hook is totally unacceptable to my workflows and I will always find a way to work around it. Like everyone else is saying, if you want to enforce some rule on the codebase then do it in CI and block merges on it.

[aljgz]

I'm the type of developer who always have a completely different way of working. I hate pre-commit hooks, and agree that pre-push + early step is CI is the right thing to do.

[pojzon]

You dont have to install hooks. Its that simple.

Be prepared to have your PR blocked tho.