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