zlacker

>>fortui+(OP)
I struggle to see value with git hooks. They're an opt-in, easily opt-out way of calling shell scripts from my understanding--you can't force folks to run them, and they don't integrate/display nicely with CI/CD.

Why not just call a shell script directly? How would you use these with a CI/CD platform?

>>candid+6a
This might be a me problem but I extensively manipulate the git history all the time which makes me loathe git hooks. A commit should take milliseconds, not a minute.

>>schind+Ef
You do seem to be doing it wrong. Extensive manipulation of the record and slow hooks are both undesirable.

>>esafak+Eq
I would reckon cleaning up your branch before opening a pull request is good practice. I also rebase a lot, aswell as git reset, and I use wip commits.

Slow hooks are also not a problem in projects I manage as I don't use them.

>>schind+Tu
No, I would not and don't do that. It is better to leave the PR commits separate and atomic so reviewers can digest them more easily. You just squash on merge.

> Slow hooks are also not a problem in projects I manage as I don't use them.

You bypass the slow hooks you mentioned? Why even have hooks then?

>>esafak+Iv
> It is better to leave the PR commits separate and atomic so reviewers can digest them more easily.

So reviewers have to digest all of the twists and turns I took to get to the final result? Why oh why oh why?

Sure, if they've already seen some of it, then there should be an easy way for them to see the updates. (Either via separate commits or if you're fortunate enough to have a good review system, integrated interdiffs so you can choose what view to use.)

In a better world, it would be the code author's responsibility to construct a meaningful series of commits. Unless you do everything perfectly right the first time, that means updating commits or using fixup commits. This doesn't just benefit reviewers, it's also enormously valuable when something goes wrong and you can bisect it down to one small change rather than half a dozen not-even-compiling ones.

But then, you said "atomic", which suggests you're already trying to make clean commits. How do you do that without modifying past commits once you discover another piece that belongs with an earlier step?

> You just squash on merge.

I'd rather not. Or more specifically, optimal review granularity != optimal final granularity. Some things should be reviewed separately then squashed together (eg a refactoring + the change on top). Some things should stay separate (eg making a change to one scary area and then making it to another). And optimal authoring granularity can often be yet another thing.

But I'll admit, git + github tooling kind of forces a subpar workflow.