<div dir="ltr">Hi all,<div><br></div><div>after the recent switch to GitHub, I&#39;ve seen that reviews that require multiple iterations are hard to follow using the old workflow we were using in Gerrit.</div><div><br></div><div>Till now we basically amended the commit and pushed it again. Gerrit had a feature to calculate diffs between versions of the patch, so it was relatively easy to follow the changes between iterations (unless there was a big change in the base branch and the patch was rebased).</div><div><br></div><div>In GitHub we don&#39;t have this feature (at least I haven&#39;t seen it). So I&#39;m proposing to change this workflow.</div><div><br></div><div>The idea is to create a PR with the initial commit. When a modification needs to be done as a result of the review, instead of amending the existing commit, we should create a new commit. From the review tool in GitHub it&#39;s very easy to check individual commits.</div><div><br></div><div>Once the review is finished, the patch will be merged with the &quot;Squash and Merge&quot; option, that will combine all the commits into a single one before merging, so the end result will be exactly the same we had with Gerrit.</div><div><br></div><div>Another thing to consider is that rfc.sh script always does a rebase before pushing changes. This rewrites history and changes all commits of a PR. I think we shouldn&#39;t do a rebase in rfc.sh. Only if there are conflicts, I would do a manual rebase and push the changes.</div><div><br></div><div>What do you think ?</div><div><br></div><div>Regards,</div><div><br></div><div>Xavi</div></div>