Hacker News new | ask | show | jobs
by bjourne 1224 days ago
Code reviews happens when you update trunk. You eye through the latest changes and if you see something particularly gregarious there you either fix it yourself or you tell them about it. People of course shouldn't commit stuff that breaks the build, but that is irrespective of whether you are using feature branches or not.
1 comments
IshKebab 1224 days ago
All these things sound highly optimistic. You're just hoping that people will run all the tests before pushing (what if CI time is over an hour?). You're hoping that people retrospectively review changes (what if the project is very big?).

I'm only seeing disadvantages compared to traditional MR/PR/diffs.

link
ilyt 1224 days ago
If they don't CI will fail and not even show that as code to review so it's not exactly an issue. And if they push to master it can always be reverted and the clown shamed. Works well enough

> You're just hoping

...yes, hoping that I'm not working with idiots and change the job if I would be.

It's different for OSS or any project with external contributor but you need to require some minimal level of competence

link
IshKebab 1224 days ago
> If they don't CI will fail

Yes, CI failing is a big issue! It means you can't bisect, and you show everyone else down while the big gets fixed.

> hoping that I'm not working with idiots

Ah you're one of those "only idiots make mistakes" types. Ok never mind; I hope you can learn that everyone makes mistakes - including you - one day, but I won't try to convince you now.

(You have successfully convinced me that trunk based development is a terrible idea though; at least for anything more than tiny teams working on small projects.)

link
ilyt 1224 days ago
Throwing some bad commit once a month is not a big deal and not "idiocy" I'm talking about. CI ain't gonna deploy it anyway. At absolute worst you'd have to "git bisect skip" it during bug hunt that one time in two years you get unlucky to hit it.

I'm talking about people that constantly do same stupid stuff or go around system put in place coz they think they are smarter and want to shave few seconds off

We do a bunch of checks in pre-commit stuff but nothing delaying it much, and trust devs will commit working tested code. So far that social contract works just fine

And yes, you can put far less baby bumpers around stuff and go faster if your co-workers are not babies that need every sharp object hidden from them.

link