[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits
Fedor Sergeev via llvm-dev
llvm-dev at lists.llvm.org
Sat Feb 2 00:18:57 PST 2019
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>>>
> > 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
> 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
> 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
> > 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
More information about the llvm-dev