[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