[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits

[Fedor Sergeev via llvm-dev]

On 2/2/19 8:27 AM, Mehdi AMINI via llvm-dev wrote:
> On Fri, Feb 1, 2019 at 4:44 PM Tom Stellard <tstellar at redhat.com 
> <mailto:tstellar at redhat.com>> wrote:
>
>     On 01/30/2019 10:53 PM, Mehdi AMINI via llvm-dev wrote:
>     >
>     >
>     > On Wed, Jan 30, 2019 at 1:19 PM Eric Christopher via cfe-dev
>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>     <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>>
>     wrote:
>     >
>     > 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?
>     >
>
>     No enforcement plan at this point, but I was planning to contact
>     github about this to
>     see what options we had.  Last time you looked into it, did you
>     talk to anyone at github
>     support?
>
>
> 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).
>
> 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.
>
>
>     This is also why I think it's important to decide early so we have
>     time to look at
>     what our options are to enforce these policies. If pull requests
>     are our only
>     option for enforcement, then I think it would be good to know that
>     before we
>     have a large debate about Phabricator vs Pull Requests.
>
>
> 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.
>
> 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.
>
> 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: 
> https://help.github.com/articles/about-required-status-checks/ ; we'd 
> have `git llvm-push` whitelisting the commit before actually pushing it.
Instead of requiring git llvm-push we can introduce a branch (e.g. 
'unverified') which on a push event performs
the action that does this whitelisting, perhaps some other quick 
verification and then just pushes further into
a protected master.

Definitely not that convenient than a pre-receive check, but at least 
something...

regards,
   Fedor.

>
> -- 
> Mehdi
>
>
>
>
>     -Tom
>
>
>     > We may write this rule in the developer guide, but I fear it'll
>     be hard to enforce in practice.
>     >
>      --
>     > Mehdi
>     >
>     >
>     >
>     > _______________________________________________
>     > LLVM Developers mailing list
>     > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev