+1 to all points here. We shouldn't allow merge commits. Rebase and merge is ok but I'd lean toward removing it if it starts to get abused. Squash and merge should be the default and used for 95% of use cases.
Best, Adnan Hemani On Mon, Jun 8, 2026 at 10:01 AM Yufei Gu <[email protected]> wrote: > +1 to disabling merge commits. > > I'd prefer squash and merge to remain the default in almost all cases. > Rebase and merge can be useful occasionally when there's real value in > preserving a meaningful commit history, but I'd treat that as the exception > rather than the norm. > > Yufei > > > On Mon, Jun 8, 2026 at 8:42 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > +1 to JB's proposal (below). > > > > Cheers, > > Dmitri. > > > > On Mon, Jun 8, 2026 at 11:28 AM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > As a follow-up to this discussion, I created > > > https://github.com/apache/polaris/pull/4649. > > > > > > I think we should disable merge commit, but I think it's fine to keep > > > "rebase and merge" as soon as it's used wisely and in special cases > > (squash > > > and merge should be the default). > > > > > > Regards > > > JB > > > > > > On Mon, Jun 8, 2026 at 4:25 PM Alexandre Dutra <[email protected]> > > wrote: > > > > > > > Hi Yong, > > > > > > > > Yes, rebase-and-merge would make sense for that PR, since we want to > > > > preserve the individual commits. Ideally, if we could reserve this > > > > strategy for branches named after "feature/*" or something in the > > > > style, I think that would be the nicest solution. But if that's not > > > > possible, enabling it is fine too, as long as we all agree to not > > > > abuse it. Which I guess comes down to the good ol' proverb: "with > > > > great power comes great responsibility" :-) > > > > > > > > Thanks, > > > > Alex > > > > > > > > On Mon, Jun 8, 2026 at 4:16 PM Yong Zheng <[email protected]> > > > wrote: > > > > > > > > > > Hi Alex, > > > > > > > > > > This is mainly for https://github.com/apache/polaris/pull/4612. > > > > > > > > > > We started with spark 3.5 and added code for spark 4.0 then later > > > > refactor those into common. Without using what JB created in this PR, > > the > > > > commit history will get squash away. Taking one example, assuming > dev A > > > > created the changes for 3.5 earlier and I tried to copy the same code > > to > > > > spark 4.0. In the commit history, it will show all codes in 4.0 are > > done > > > by > > > > me. And the problem may get worse over time such as spark 3.5 EOL > then > > we > > > > dropped the support for 3.5 completely. In this case the commits made > > by > > > > dev A will be no where to be found from 4.0. > > > > > > > > > > Thanks, > > > > > Yong Zheng > > > > > > > > > > > On Jun 8, 2026, at 8:39 AM, Alexandre Dutra <[email protected]> > > > wrote: > > > > > > > > > > > > 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 > > > > > >>>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>> > > > > > >>>>> > > > > > >>> > > > > > > > > > >
