On 03/19/2019 11:59 AM, Tom Stellard via Openmp-dev wrote: > Hi, > > I would like to follow up on the previous thread[1], where there was a > consensus > to disallow merge commits in the llvm github repository, and start a > discussion > about how we should enforce this policy. > > Unfortunately, GitHub does not provide a convenient way to fully enforce this > policy. > We can enforce it for pull requests, but not for direct pushes to the master > branch, > so we will have to come up with our own solution if we want to completely > prevent > merge commits. I've spent some time looking into this and here are a few > options that I've come up with (If you are a GitHub expert and have other > suggestions, please let us know): > > 1. Have either a status check or use the "Rebase and Merge" policy for pull > requests > to disallow merge commits. Disable direct pushes to the master branch and > update the > git-llvm script to create a pull request when a developer does `git llvm > push` and > then have it automatically merged if there are no merge commits. > > 2. Enforce no merge commits for pull requests, but sill allow developers to > push directly > to master without checking for merge requests. This is essentially a best > effort > approach where we avoid having to implement our own custom work-flow for > committing, > while accepting the possibility that someone might accidentally push a merge > commit. > > 3. Disable direct pushes to master, don't update the git-llvm script and > require all > developers to use pull requests, where this policy will be enforced. > > Which option do you prefer? >
Thanks everyone for responding to this thread. Based on the responses, the preferred solution is none of these options and instead having a server-side check to prevent merge commits. I have been in contact with someone at GitHub who is looking into this for us to see if this would be possible. As a backup plan, I am going to look into implementing option #1, but instead of having git-llvm create a pull request, it would push first to a staging branch and then push to master if a 'no-merge commit' status checks pass. This is essentially the same flow as using pull requests, but without all the pull request noise. The reason to go #1 as a backup is that it preserves the status quo we have now where developers commit using git-llvm and based on the limited feedback seems like the preferred option of these 3. - Tom > -Tom > > [1] http://lists.llvm.org/pipermail/llvm-dev/2019-January/129723.html > _______________________________________________ > Openmp-dev mailing list > openmp-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
