<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 22, 2020 at 11:24 PM David Greene <<a href="mailto:greened@obbligato.org">greened@obbligato.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Christian Kühnel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
>>> In Github pull requests there is always a git commit that you can just<br>
>>> feed to the build server. And you can be sure of what really gets merged.<br>
>>> You review, build and test exactly the change that gets merged afterwards.<br>
>>><br>
>><br>
>> How would that be true? Given that upstream keep changing during the<br>
>> period of review? The commit is going to have to be rebased to head and<br>
>> that may involve making changes.<br>
>><br>
><br>
> Yes, github tells you, that your PR has a merge conflict, that you need to<br>
> resolve manually. Once you've pushed the conflict resolution to the same<br>
> PR, it triggers another round of builds and tests. And also potentially<br>
> another review, depending on what permissions you have and how the project<br>
> ist set up...<br>
<br>
It's not quite that simple though.  In general most PRs will need to be<br>
rebased just before merging to maintain linear history.  </blockquote><div><br></div><div>That depends on how frequent merge conflicts are. In my other projects that wasn't really an issue. I rarely had to rebase something manually.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What happens<br>
then?  Would things need to pass another build before the "final merge?"<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If so, then something needs to keep a list of pending PRs waiting for<br>
"final merge."  This quickly gets very hairy as pending PRs have to<br>
constantly be rebased and rebuilt as other PRs land.<br></blockquote><div><br></div><div><div>Some projects have a flag they set and let some bot do the manual work: Rebase, re-test and then automatically merge.<br></div><div>I do not expect this to be perfect, it should rather be much better than today in slipping new bugs into master.<br></div></div><div><br></div><div>-- <br></div></div><div dir="ltr" class="gmail_signature"><div dir="ltr">Best,<div>Christian</div></div></div></div>