Elijah Newren <newren@xxxxxxxxx> writes: > 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. :-) In fact I didn't read it, I rather re-read it ;-) (I'm in the CC list there, so it should not have been a surprise I did read it then.) > >> "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. There were quite a few tests performed and methods were polished before Johannes has been persuaded to give the feature a try, some of the tests being complex enough, and both methods did perform rather well. That is what he calls "initial tests" there I believe, and then he found the case that is very important to him, but lead him to nested merge conflicts, that is indeed quite bad. > >> 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. Well, it was you who gave me the reference to comment on, and that was the only disadvantage I was able to find being discussed there. I also don't recall any other objections back then when the problem has been discussed a lot. >> 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. You just repeat saying the same thing, without any further arguments? OK, thank you for your opinion anyway. > (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.) It works. Really. > >> 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. >From my POV particular problem space (rebasing commits) already uses the diffs, and only them, that's why I can't figure how you end up coming to such conclusion. > > 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. OK, I participate only in hope that there will be somebody who actually cares enough to implement it. Maybe it will be me, maybe not, and I already got it that neither you nor the original author of git-rebase are interested. > I still believe in my proposed solution, and I'll implement it as I > get time for it. Sure it'd be nice. Fortunately there is nothing mutually exclusive here. Thanks, -- Sergey Organov
