[ahartmetz]

>On Github, the unit of code review is the PR.

It is, and that is some bullshit. The only sensible way to work with that is to break up larger features into several PRs - which is often positive anyway, but sometimes it doesn't fit the nature of the change.

[xen0]

I am not a fan of Github's interface.

But my point is, is that I believe the important thing to preserve in history is whatever your unit of review is. If you could stack PRs and each were subject to the individual review, I would not combine and squash those (just the individual commits within each PR).

[ahartmetz]

>I believe the important thing to preserve in history is whatever your unit of review is

I do not share that belief, but this thread (your posts and others) gave me an idea about code reviews. They became commonplace when I'd been working in software for a while already and, while I see the benefits, I never really felt like I handled them well. I guess one of the ingredients for handling them better is to center the workflow around them - an area in which I have never noticed major changes in an existing project, although they are visible when looking from the right angle: Long-lived, large feature branches have become noticeably less common.