This just seems to conflate PRs & commits, or not care about the latter at all; the perspective of someone who files a PR with 100 commits like 'fix typo', 'try

This just seems to conflate PRs & commits, or not care about the latter at all; the perspective of someone who files a PR with 100 commits like 'fix typo', 'try again', 'the test broke', etc. > For speed and quality, PRs should be maintained under 200 lines—with 50 lines being ideal. Is maybe a reasonable goal for a commit. The PR should then have as many of those commits (which probably doesn't strictly sum their LoC count) as necessary for the feature/fix. Edit: In fact - I thought this was familiar, I just couldn't find a past submission from the same URL, because it was a newsletter puff-piece - I've said similarly before here: https://news.ycombinator.com/item?id=37917559 https://news.ycombinator.com/item?id=37917559 Also related, even more recently, is GitButler: https://news.ycombinator.com/item?id=39357068 https://news.ycombinator.com/item?id=39357068 which despite my scepticism there I think is a better solution for this 'problem' (i.e. an easier way to handle rebasing dependent branches) than for some reason having to up-end code review as a side-effect; I don't really understand the link at all if you look at Graphite's home page and 'learn more about stacking', nice to make that easier but what's it got to do with how we review the changes on those branches?