<div dir="ltr"><div dir="ltr"><a href="https://help.github.com/articles/checking-out-pull-requests-locally/">https://help.github.com/articles/checking-out-pull-requests-locally/</a><br></div><div dir="ltr"><br></div><div>Script a bot to scrape the patches and post to phabricator?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Feb 2019 at 04:22, Roman Lebedev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.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">On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> writes:<br>
><br>
> > What is the practical plan to enforce the lack of merges? When we<br>
> > looked into this GitHub would not support this unless also forcing<br>
> > every change to go through a pull request (i.e. no pre-receive hooks<br>
> > on direct push to master were possible). Did this change? Are we<br>
> > hoping to get support from GitHub on this?<br>
> ><br>
> > We may write this rule in the developer guide, but I fear it'll be<br>
> > hard to enforce in practice.<br>
><br>
> Again, changes aren't going through git yet, right?  Not until SVN is<br>
> decommissioned late this year (or early next).  SVN requires a strict<br>
> linear history so it handles the enforcement for now.<br>
<br>
> My personal opinion is that when SVN is decomissioned we should use pull<br>
> requests, simply because that's what's familiar to the very large<br>
> development community outside LLVM.  It will lower the bar to entry for<br>
> new contributors.  This has all sorts of implications we need to discuss<br>
> of course, but we have some time to do that.<br>
My personal opinion is an opposite of that one.<br>
<br>
*Does* LLVM want to switch from phabricator to github pr's?<br>
I personally don't recall previous discussions.<br>
Personally, i hope not, i hope phabricator should/will stay.<br>
<br>
Low bar for entry is good, but not at the cost of raising the bar<br>
for the existing development community.<br>
In particular, i'm saying that github's ui/workflow/feature set<br>
is inferior to that one of phabricator.<br>
<br>
Is the low entry bar the only benefit?<br>
While it is good, it should not be the only factor.<br>
The contributors will already need to know how to build LLVM,<br>
write tests, make meaningful changes to the code.<br>
Additionally having to know how to work with phabricator<br>
isn't that much to ask for, considering the other prerequisites..<br>
<br>
> If we don't use PRs, then we're pretty much on the honor system to<br>
> disallow merges AFAIK.<br>
><br>
>                              -David<br>
Roman.<br>
<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>