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

[Tao Klerks <tao@klerks.biz>]

On Mon, Feb 20, 2023 at 5:56 PM Elijah Newren <newren@gmail.com> wrote:
>
> The strategies described by Buga and others in that mega-thread were
> suboptimal solutions, in my opinion.  Johannes went and implemented
> some and found them wanting; see the thread over at
> https://lore.kernel.org/git/nycvar.QRO.7.76.6.1804130002090.65@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz/.

Ah, thank you! I think you had mentioned this before, and I somehow
lost track of this.

At first I want to summarize this concern as "any strategy that treats
a merge rebase as a *pair* of cherry-picks risks encountering
nested/overlapping merge conflicts", but I must be understanding too
superficially, as you then mention arbitrary conflict nesting (and I
assume this is not about octopus merges).

> There were follow-ups with an improved strategy in the thread over at
> https://lore.kernel.org/git/CABPp-BHWVO5VRhr1-Ou60F1wjKzJZ1e_dC01Mmzs+qB9kGayww@mail.gmail.com/
> (Note that this route has also independently been discovered and
> implemented in jj and found to work well, though it does handle
> conflicts much differently).  And I've since improved the strategy
> further at https://github.com/newren/git/blob/e84f5f3585fd770ed21f398d2ae5f96e90a51b1e/replay-design-notes.txt#L264-L341.
> However, note that this isn't a case of merely performing the proper
> series of merges, it needs some specialized logic and some new
> capabilities at the xdiff level.

Understood - thanks for the update, and of course for all your
continued work on this.

Is it fair to say that, for the simple situations that Phillip's
cherry-pick strategy *does* kick in for, the outcome should be exactly
the same as the outcome of the replay strategy?