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
