Hacker News Reader

Comment by LaLaLand122 | Hacker News Reader

> if someone makes changes since the last time I reviewed and then they force push I can’t see the difference from the last time I reviewed

You need better tools. Even in GitHub you can click on "force pushed" and see the diff.

> there’s no guarantee they would all pass CI

There wasn't any guarantee before, either. If you want that guarantee, make the CI build every commit.

View on HN

> There wasn't any guarantee before, either. If you want that guarantee, make the CI build every commit.

Guarantee is the wrong word. The point is that if you always squash merge after passing the entire test suite you don’t have a bunch of potential garbage commits in history that you have to wade through when bisecting.

As for building every commit that’s probably a tough sell and a poor use of money for what benefit?

But if it's only gonna find monstrous feature-at-a-time commits, what good is a bisect anyway? I want the culprit commit to be 5 minutes of bad ideas, not 5 minutes of bad ideas mixed with three days of good ones.

Make smaller PRs then. It's a lot slower to bisect if only some of the commits even compile.

If the PR is small enough to naturally fit into a single commit the rebasing vs squashing multiple commits discussion disappears (just please don't merge it!)... there is a single commit.

Many developers make commits that are “wip” with messages to match. Maybe you commit before you go to lunch, or when you go home for the day. These are useless commits and should be rebased or squashed, but many of these same devs won’t do that unless you force them or the tooling does it for them automatically. A minority of devs build a clean history of commits that tells a story, carefully crafted over time (usually manufactured after the fact with liberal use of rebase). For these devs squash is awful. Unfortunately they are truly a minority and the majority ruins things for them.

Reply on news.ycombinator.com