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

>
> On Thu, Feb 16, 2023 at 8:02 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> >
> > On Thu, Feb 16, 2023 at 5:31 AM Tao Klerks <tao@klerks.biz> wrote:
> > >
> > > If there's an appetite for it, I would love to contribute to a
> > > multi-year adventure to change git's behavior, little by little, until
> > > the behavior of "rebase=merges" is the default, and the old behavior
> > > becomes a different option like
> > > "rebase=copy-merged-commits-to-flatten"
> >
> > I know you had a lot to say in your last email, but I'd like to focus
> > on this point. I would be OK with the proposed patch if it were part
> > of a larger effort to make --rebase-merges the default behavior of
> > `git rebase`. That seems like an achievable goal, and I don't think it
> > would take multiple years, maybe one year at the most. The process
> > would look something like this:
> >

> >
> > Does that sound reasonable? I think I could lend a hand with steps 1-3.
>
> One concern I have is that "--rebase-merges" itself has negative user
> surprises in store.  In particular, "--rebase-merges", despite its
> name, does not rebase merges.  It uses the existing author & commit
> message info, but otherwise just discards the existing merge and
> creates a new one.  Any information it contained about fixing
> conflicts, or making adjustments to make the two branches work
> together, is summarily and silently discarded.
>
> My personal opinion would be adding such a capability should be step
> 2.5 in your list, though I suspect that would make Tao unhappy (it's a
> non-trivial amount of work, unlike the other steps in your list).