[llvm-dev] Phabricator -> GitHub PRs?

Christian Kühnel via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 23 08:57:32 PST 2020


On Thu, Jan 23, 2020 at 5:47 PM David Greene <greened at obbligato.org> wrote:

> Christian Kühnel <kuhnel at google.com> writes:
>
> >> It's not quite that simple though.  In general most PRs will need to be
> >> rebased just before merging to maintain linear history.
> >
> >
> > 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.
>
> It has little to do with merge conflicts.  Because LLVM requires
> fast-forward merges, everything has to be rebased after something else
> gets merged.
>

This is done by github PR automagically as long as there are no merge
conflicts.


>
> >> What happens then?  Would things need to pass another build before
> >> the "final merge?"
> >>
> >> If so, then something needs to keep a list of pending PRs waiting for
> >> "final merge."  This quickly gets very hairy as pending PRs have to
> >> constantly be rebased and rebuilt as other PRs land.
> >
> > Some projects have a flag they set and let some bot do the manual work:
> > Rebase, re-test and then automatically merge.
> > I do not expect this to be perfect, it should rather be much better than
> > today in slipping new bugs into master.
>
> I agree the process can be improved.  But at some point builders are
> going to be backed up as each PR gets rebased and then rebuilt just
> before merging.  Probably we will have to punt an assume that if the
> rebase is clean, it can just be merged in without another build.  We
> will miss some small cases where non-conflicting code interacts in bad
> ways but as you said, no system is perfect.
>

Yes, I agree.


-- 
Best,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200123/bde5894a/attachment.html>


More information about the llvm-dev mailing list