<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 1, 2019 at 4:44 PM Tom Stellard <<a href="mailto:tstellar@redhat.com">tstellar@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 01/30/2019 10:53 PM, Mehdi AMINI via llvm-dev wrote:<br>
> <br>
> <br>
> On Wed, Jan 30, 2019 at 1:19 PM Eric Christopher via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>> wrote:<br>
> <br>
> On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>> wrote:<br>
> ><br>
> > Bruce Hoult via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> writes:<br>
> ><br>
> > > How about:<br>
> > ><br>
> > > Require a rebase, followed by git merge --no-ff<br>
> > ><br>
> > > This creates a linear history, but with extra null merge commits<br>
> > > delimiting each related series of patches.<br>
> > ><br>
> > > I believe it is compatible with bisect.<br>
> > ><br>
> > > <a href="https://linuxhint.com/git_merge_noff_option/" rel="noreferrer" target="_blank">https://linuxhint.com/git_merge_noff_option/</a><br>
> ><br>
> > We've done both and I personally prefer the strict linear history by a<br>
> > lot. It's just much easier to understand a linear history.<br>
> ><br>
> <br>
> Agreed. Let's go with option #1.<br>
> <br>
> <br>
> What is the practical plan to enforce the lack of merges? When we looked into this GitHub would not support this unless also forcing every change to go through a pull request (i.e. no pre-receive hooks on direct push to master were possible). Did this change? Are we hoping to get support from GitHub on this?<br>
> <br>
<br>
No enforcement plan at this point, but I was planning to contact github about this to<br>
see what options we had. Last time you looked into it, did you talk to anyone at github<br>
support?<br></blockquote><div><br></div><div>Yes, and they pointed to the web hooks they have (but these are only post-commit I believe) and they pointed to the pull-request policy to enforce this. They said they wasn't any other option (at the time).</div><div><br></div><div>If a custom pre-receive hook is out of the realm of possible, maybe they could add as a new "branch protection" setting that would "enforce linear history" on a branch. This seems like a reasonable feature that other people may want.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
This is also why I think it's important to decide early so we have time to look at<br>
what our options are to enforce these policies. If pull requests are our only<br>
option for enforcement, then I think it would be good to know that before we<br>
have a large debate about Phabricator vs Pull Requests.<br></blockquote><div><br></div><div>If we use pull-request as a tool for ensuring linear history, we don't *have to* do the reviews there: it would be possible to continue doing the reviews on the mailing list and on Phabricator, and just open a PR after approval to use the "Rebase and merge" to get the change in immediately.</div><div><br></div><div>I'm not sure the "not do any review on the pull request" while having to open a PR for any change anyway will be practical though, at this point folks may just naturally start reviewing there directly.</div><div><br></div><div>Another idea I floated around is to force to use `git llvm-push` instead of `git push` and have it check that no merge is about the be pushed. We could prevent direct use of `git push` by using this "branch protection" feature: <a href="https://help.github.com/articles/about-required-status-checks/">https://help.github.com/articles/about-required-status-checks/</a> ; we'd have `git llvm-push` whitelisting the commit before actually pushing it.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
-Tom<br>
<br>
<br>
> We may write this rule in the developer guide, but I fear it'll be hard to enforce in practice.<br>
><br>
-- <br>
> Mehdi<br>
> <br>
> <br>
> <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>
> <br>
<br>
</blockquote></div></div></div></div></div>