+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* >> >
