Hi, So if u did a 'git mv old new', the new file is till been tracked and will keep the history. However, if u do `git mv old common` then create a new old file (similar to what we are doing in the spark one, only one of the file will have history (in this case the common will have history and old won't have). To save the history on both, we will need to do the move then commit and reset head of the move file (so the restored file along with common will share history).
Then back to this specific example, the trick above will only work if we are doing non-squash merging as if we do a squash merge, the commit history would be gone again thus only one will have historical. Thanks, Yong On 2026/06/08 15:33:50 Dmitri Bourlatchkov wrote: > 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 > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>> > > >>> > > >
