<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>In Github pull requests there is always a git commit that you can just feed to the build server. And you can be sure of what really gets merged. You review, build and test exactly the change that gets merged afterwards.<br></div></div></div></div></blockquote><div><br></div><div>How would that be true? Given that upstream keep changing during the period of review? The commit is going to have to be rebased to head and that may involve making changes.</div></div></div></blockquote><div><br></div><div>Yes, github tells you, that your PR has a merge conflict, that you need to resolve manually. Once you've pushed the conflict resolution to the same PR, it triggers another round of builds and tests. And also potentially another review, depending on what permissions you have and how the project ist set up...</div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best,<div>Christian</div></div></div></div>