> If we rebase-and-merge those, all that noise lands on main. That's why I said "when used wisely": this strategy can be useful e.g. if a feature branch, containing many meaningful, independent commits, is to be rebased on top of main. "Squash and merge" would squash everything together which is too coarse-grained. But apart from this use case, I don't see other useful usages of "rebase and merge", and having it enabled means we need to trust all committers to pick the best merge strategy carefully.
Thanks, Alex On Mon, Jun 8, 2026 at 11:45 AM Robert Stupp <[email protected]> wrote: > > Hi, > > My main concern with rebase-and-merge is that many PRs naturally collect > random cleanup commits during review: fixing formatting, addressing one > comment, fixing CI, another small tweak, etc. > > If we rebase-and-merge those, all that noise lands on main. > I don’t think that makes the history better. > Usually the useful unit is the PR, not every intermediate commit someone > pushed while getting it ready. > > So I’m fine with disabling merge commits, but I’d probably also keep rebase > disabled unless we have a clear rule that it’s only used for PRs with a > clean, intentional commit series. > > Robert > > On Mon, Jun 8, 2026 at 11:16 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > We can keep our boy squash and merge and rebase and merge, and disable > > merge commit. > > > > Le lun. 8 juin 2026 à 09:47, Alexandre Dutra <[email protected]> a écrit : > > > > > 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 > > > > > > > > > > > > > > > >
