[papyrus9244]

One of my pet peeves with git (and systems both similar, and based on it) is that automated tests run after you've made the commit and push.

In my mind the commit (let alone the push to a publicly accesible server) should be done after, and only if, the automated tests are successfully executed. And there's no easy way to implement this, other than having a dirty branch that you discard after rebasing onto a more long lived one.

[sethammons]

There are lots of reasons to commit when things are yet working. How else would you share code that you need help with?

The solution is gated merges. No merging to main unless ci passes.

Every org I have worked at bemoaned a flaky release process and refused e2e black box acceptance tests because "they are too slow." And every org I have worked at has realized they were wrong. We got appropriate gates that run in 5 minutes and an ops person is the only person who can force past any gate in case of emergency.

Guardrails like this only become more important with the accelerant that is ai.

[10000truths]

You can use a pre-receive hook on a git server to reject pushes that fail compilation. Downside is that it requires admin access on git forges, so you're only able to do this if you self-host.

[jwolfe]

Pre commit hooks exist. People just don't like being prevented from committing for reasons such as this.