On Sun, Feb 26, 2023 at 1:29 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > > 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: I'm glad you read it. :-) > "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, Jumping from "performed well on initial tests" to "performs well in general" seems to me to be quite a large and unwarranted logical leap. > and we just need to > avoid driving ourselves into nested merge conflicts I'm glad you're discussing a disadvantage and how to address it, but I don't understand how you can jump to the implication that this is the only one. > 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. The use of superlatives and asterisks doesn't change my opinion; I'm still skeptical that the given strategy is overall a step forward, let alone a large one. (I do agree we have a huge problem and thus that a huge step forward theoretically could be taken, I just don't see this as it.) > 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? I have no hate for such diffs; I just firmly believe they are inappropriate as a solution for the particular problem space being discussed. But I've stated that more than enough, and no one is producing patches on this topic right now, so I'll drop out of this thread. I still believe in my proposed solution, and I'll implement it as I get time for it.
