Hi All, Re: PR [4612] - I actually tried squash-merging it into `main` locally and line attribution appeared to be preserved on the moved code. Perhaps I'm missing something about the history problem in a squashed merge.
In any case, I'm fine with the rebase-and-merge workflow as long as it is "used wisely". As for merge commits, I'd prefer to avoid them on `main`. [4612] https://github.com/apache/polaris/pull/4612 Cheers, Dmitri. On Mon, Jun 8, 2026 at 10:16 AM 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 > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>>> > >>> >
