Elijah Newren <newren@xxxxxxxxx> writes: > On Sat, Feb 25, 2023 at 7:15 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: >> >> Elijah Newren <newren@xxxxxxxxx> writes: >> >> > On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov <sorganov@xxxxxxxxx> wrote: >> >> >> >> Elijah Newren <newren@xxxxxxxxx> writes: >> >> [...] >> >> > Please, go read at least [1] to see Johannes comments about how the >> > prior proposals don't work beyond simple cases. >> >> It's exactly handling of simple cases that we need most. We can get >> fancy afterwards, if feasible. > > If we can handle just the simple cases without making common cases > significantly worse, that'd be a potential path forward. Any proposal > involving the diff between a merge commit and either of its parents > (or an equivalent such as a three-way merge involving the merge commit > and one of its parents) doesn't achieve that, IMO. Except the method discussed does achieve exactly that according to the evidence gathered at the time of debates, and here is confirmation (from Johannes himself) from the reference you provided: "This strategy, while it performed well in my initial tests (and in Buga's initial tests, too), *does* involve more than one 3-way merge, and therefore it risks something very, very nasty: *nested* merge conflicts." So, overall, the method performs well in general, and we just need to avoid driving ourselves into nested merge conflicts, as resolving them is beyond capabilities of most human beings. Setting this back into perspective, in comparison to blind re-merge, that fails to keep user changes even when no conflicts at all exist, and even when it's applied at the same place in the history, the discussed method is a *huge* step forward, especially if re-merge is kept as a fallback strategy. P.S. BTW, where this hate for using of diffs with respect to parents come from, I wonder, provided we do use them all the time anyway? Thanks, -- Sergey Organov
