I'll never understand people caring about commit in PRs, just push whatever and squash at the end. If commit matters that means you should have done multiple PRs

▲

jon-wood 3 days ago | parent [-]

And I will never understand people not caring about commits and just going "we'll squash it all anyway". I think of these things as different levels of granularity, the PR is a complete feature, while the commits are the steps taken to get to that feature. By splitting your PR into coherent commits you make review easier by allowing each commit to be reviewed in isolation.

It will forever infuriate me that Github's code review UI buries commits in favour of a big blob of changes without context, more so because that UI is generally considered Good Enough by most people, discouraging any innovation around code review.

	▲	yencabulator a day ago \| parent \| next [-]
		It's the difference between people who have had to troubleshoot obscure problems in complex systems and people who haven't.. Software archeology is important. My personal route: clean atomic commits that do one thing at a time and are justifiable on their own, rebased to minimize small-scale concurrent branches littering the history.
	▲	habosa 3 days ago \| parent \| prev [-]
		Actually, at this point GitHub’s total failure to make a decent code review UI has inspired a lot of innovation! I think graphite.dev is the most well-known, but I’m also a fan of others reviewable.io and codepeer.com … I know this space well because I made codeapprove.com to improve code review on GitHub.