How pull request revisions will handle rebases

GitHub plans to enhance pull requests with revisions. The idea looks nice, but there is one point that confuses me.

Say, I created a patchset based on a main branch, sent it for review, collected feedback, marked the PR as draft, updated the PR, resolved all comments and now I’m ready to mark it as ready-for-review again.

The point ‘updated the PR’ assumes that I made all requested changes (changed my patchset) and usually means that I rebased my changes on the new main to ensure seamless pushing to main.

This way I protect myself from potential problems that may appear due to old-main and new-main differences, which do not lead to merge/rebase conflicts, but may be revealed by testing in CI. Aside of this, a developer may want to rebase due to main changes around components relevant to the patchset. This is especially important for large features, where a review iteration may take significant time and many review iterations may be required.

So, the difference between revisions includes not only my changes, but also latest main changes. However a reviewer usually want to concentrate on the patchset changes.

The obvious workaround would be spawning a fake revision, where I just rebase my old patchset on top of the latest main. It is not quite convenient (requires extra branch juggling), so it would be neat if GitHub would consider such development flow as somewhat natively supported and would provide a clear view on the difference between revisions.

I don’t know whether GitHub plans to support such development flow and so I’m worried a bit.