+1 to enforce the behavior recommended in the committer guide. I usually ask
the author to manually squash before
committing.
Etienne
Le lundi 16 avril 2018 à 22:19 +0000, Robert Bradshaw a écrit :
> +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
> > >
> > > 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
> > >
