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

[David Greene via lldb-dev]

Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes:

> 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.

This seems to be the least disruptive to existing developers while
maintaining the invariant we want.  It has the advantage of potentially
being extended in the future to add additional criteria for merges
(e.g. "it builds" or "it passes this set of tests").

> 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.

To me this is the least desirable.  I'd prefer we have one way of
getting changes into the repository.

> 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.

I am completely fine with this.  It's friendlier to new contributors.
That said, I assume with #1 we wouldn't prevent users from git push-ing
their local branch to GitHub (i.e. not using git llvm push) and manually
opening a PR, so either #1 or #3 works for new developers.

> Which option do you prefer?

Maybe a slight preference for #1 as being less disruptive than #3 but I
really don't care either way.

                          -David