On Mon, Feb 20, 2023 at 5:56 PM Elijah Newren <newren@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/. 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@xxxxxxxxxxxxxx/ > (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?
