> No, no git magic. Just source code changes. One commit with the whole review that contains fixes and maybe a few questions. Then a commit from the PR author o

> No, no git magic. Just source code changes. One commit with the whole review that contains fixes and maybe a few questions. Then a commit from the PR author on top of that that adds explanations and/or fixes for the questions. Reviews on some projects will ask you to make a commit/patch in between your third and fourth (out of seven). And to fix a typo in the fifth commit message. And do fix something in the second commit that leads to conflicts in the next commits. And then to end up with for example seven commits that each “do one thing” or whatever. So if the expectation is that you end up with one “fixed up“ commit at the end of the review process which encapsulates the whole PR then this won't work. With your approach I imagine going in several rounds where 1. Reviewers leave comments 2. I address them 3. I publish that as review round X 4. I “clean up“ the history (get rid of comments/all review history) and address things like “make a doc commit before commit number 4” 5. Publish that as the “blank slate” (no comments) for the next round 6. Invite the reviewers to the next round And that could work. Something more dynamic/less rigorous (with rounds) and you might end up with an excessive amount of history rewriting and conflict resolution.