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