Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer "merges" vs "true"

>
> On Thu, Feb 16, 2023 at 7:33 AM Tao Klerks <tao@klerks.biz> wrote:
> > On Thu, Feb 16, 2023 at 4:22 AM Alex Henrie <alexhenrie24@gmail.com> wrote:
>
> > > Now, this is not to say that there's no room for improvement. I like
> > > the rebase=merges option and I wish everyone knew about it because
> > > there are situations where it really is the best option. I suggest
> > > leaving the existing text alone, but adding an additional paragraph,
> > > something like:
> > >
> > > Note that --rebase or pull.rebase=true will drop existing merge
> > > commits and rebase all of the commits from all of the merged branches.
> > > If you want to rebase but preserve existing merge commits, use
> > > --rebase=merges or pull.rebase=merges instead.
> >
> > My primary motivation with this pull request is to reduce the
> > incidences, out there in the world, of people copy-pasting "git config
> > pull.rebase true" into their command-line, and causing themselves
> > major headaches days or weeks later. The "--rebase=interactive" part
> > is secondary (to my concerns), because it's much less copy-pastable.
>
> That's because the whole approach to the pull.rebase configuration is
> wrong. I explained why multiple times in countless discussions and git
> developers did not listen.
>
> What we need is a pull.mode configuration that is *orthogonal* to
> pull.rebase, then everything just works.
>
> For example, you could have this configuration.
>
>     git config pull.mode merge
>     git config pull.rebase merges
>
> Then doing `git pull --rebase` would do a merges rebase.
>
> This is not possible with the current approach, which I objected to.
>
> Then there's no problem with telling the users to do pull.mode=rebase
> (or whatever), since that doesn't override pull.rebase=merges.
>
> I programmed and explained this precise interaction with rebase=merges
> more than two years ago [1], but nobody listened. For an example of
> how such configuration would look like, see the patches I just sent
> [2].
>
> Cheers.
>
> [1] https://lore.kernel.org/git/20201218211026.1937168-14-felipe.contreras@gmail.com/
> [2] https://lore.kernel.org/git/20230228140236.4175835-1-felipe.contreras@gmail.com/T/#t