[llvm-dev] [Openmp-dev] [GitHub] RFC: Enforcing no merge commit policy

[Tom Stellard via llvm-dev]

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-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>