Hi JB, Did you have a specific use case in mind when you opened the PR?
And out of curiosity, is it possible to keep "rebase and merge" disabled globally but selectively enabled for some "special" branches? Thanks, Alex On Mon, Jun 8, 2026 at 12:50 PM Jean-Baptiste Onofré <[email protected]> wrote: > > Let’s wait other feedback. I agree for merge commit: it should be disabled. > However rebase and merge can be informal and I trust the committers to use > the best strategy. Generally speaking I always prefer squash and merge with > multiple smaller PRs but I also understand that in some case we can prefer > larger PRs with commits. > > Regards > JB > > Le lun. 8 juin 2026 à 11:57, Alexandre Dutra <[email protected]> a écrit : > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > >
