[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits (original) (raw)

Fedor Sergeev via llvm-dev llvm-dev at lists.llvm.org
Sat Feb 2 00🔞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>>> 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

More information about the llvm-dev mailing list