+1, though I'll admit I've been an occasional user of the "squash and
merge" button when a small PR has a huge number of small, fixup changes
piled on it.

On Mon, Apr 16, 2018 at 3:07 PM Kenneth Knowles <k...@google.com> wrote:

> It is no secret that I agree with this. When you don't rewrite history,
> distributed git "just works". I didn't realize we could mechanically
> enforce it.
> Kenn
> On Mon, Apr 16, 2018 at 2:55 PM Andrew Pilloud <apill...@google.com>
> wrote:
>> *The Github UI provides several options for merging a PR hidden behind
>> the “Merge pull request” button. Only the “Create a merge commit” option
>> does what most users expect, which is to merge by creating a new merge
>> commit. This is the option recommended in the Beam committer’s guide, but
>> it is not necessarily the default behavior of the merge button.A small
>> cleanup PR I made was recently merged via the merge button which generated
>> a squash merge instead of a merge commit, breaking two other PRs which were
>> based on it. See https://github.com/apache/beam/pull/4991
>> <https://github.com/apache/beam/pull/4991>I would propose that we disable
>> the options for both rebase and squash merging via the Github UI. This will
>> make the behavior of the merge button unambiguous and consistent with our
>> documentation, but will not prevent a committer from performing these
>> operations from the git cli if they desire.Andrew*

Reply via email to