Hi JB. While I see *some* value in the "rebabse & merge" strategy when used wisely, I can hardly imagine a situation where "merge commit" is useful. OTOH, it would be really bad if someone used "merge commit" to merge a PR onto main.
So I'm globally -0 on the idea. Thanks, Alex On Mon, Jun 8, 2026 at 7:51 AM Jean-Baptiste Onofré <[email protected]> wrote: > > Hi Yong > > No worries :) I don't see issue with that. We will revert if someone has a > strong concern (I don't see why as the previous behavior is still > available). > > Regards > JB > > On Sun, Jun 7, 2026 at 8:25 PM Yong Zheng <[email protected]> wrote: > > > +1 > > > > Sorry, I didn't saw this ML and merged the PR already. We can revert that > > in case preferred. > > > > Thanks, > > Yong > > > > On 2026/06/07 16:56:54 Jean-Baptiste Onofré wrote: > > > Hi folks, > > > > > > I created the PR [1] to enable three actions on the GitHub Merge button: > > > - Squash and merge (the only action we can do today) > > > - Create a merge commit (preserving the history/commits) > > > - Rebase and merge (preserving the history/commits) > > > > > > You can find more information about what it means here: > > > > > https://docs.github.com/fr/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request > > > > > > [1] https://github.com/apache/polaris/pull/4634 > > > > > > Concretely, once this PR is merged, the merge button will have a dropdown > > > menu to select the desired action. > > > > > > Thoughts? > > > > > > Regards > > > JB > > > > >
