On Wed, Feb 22, 2023 at 6:27 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > > Tao Klerks <tao@xxxxxxxxxx> writes: > > > On Sat, Feb 18, 2023 at 5:39 PM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > >> > >> On 18/02/2023 03:17, Elijah Newren wrote: [...] > I also agree (in particular with Buga) that from the POV of user > experience the method suggested by Phillip should be superior, as it > emphasizes the natural dominance of the "current branch", as opposed to > originally described symmetric method that is more suitable for formal > analysis than for actual convenient implementation. Yet creating U1' and > U2' from the original method could be useful for the purpose of checking > for possible problems with automatic rebase that the user may need to be > aware of. > > The biggest problem here, as I see it, is designing UI that'd make sense > in the case of conflicts in multiple stages of the suggested algorithms, > but I think we can simplify it for now by stopping and suggesting blind > re-merge in case of any conflict but that on rebasing of changes to the > first parent. Even this would be a huge step forward compared to silent > drop of merge commits and blindly re-merging of updated parents. I'm not so sure it's a huge step forward. Or even a step forward. Dscho actually implemented the old proposals and tried them out, as mentioned in the threads I linked to. The results on balance were significantly worse to him than just throwing away the previous merge resolution information and redoing the merge from scratch. He really wanted a better solution, but the previous proposals didn't provide it. This newer approximation, while more careful about only attempting to run in specific cases and having some good ideas to improve the user experience, still builds on the problematic foundations in those old suggestions (namely, cherry-picking merges relative to either of their parents). I think it isn't careful enough about the subset of cases where those problematic foundations can work right. > > Are there *any* circumstances where the new cherry-picking behavior > > introduced here wouldn't be the right thing to have happen? Yes, I can think of one fairly readily: Do an interactive rebase and drop one or more commits on the side-branch being merged. This cherry-picking of merges would reinstate those dropped changes via silently squashing them into the merge commit itself, making for a rather evil merge. > None that I'm aware off, but I admit I'm not familiar with later Elijah > work on the subject, so I could be mistaken. I only got a sketchy look > at what Elijah did, and it looks like advanced material to me. I'd > incline to rather get solid implementation of basics first, probably > using Phillip method, then consider advanced methods if practice reveals > demands for further improvements. That'd be fine if there's another solution that can provide a "solid implementation of the basics"; I've not seen another proposal that can yet. > I'm afraid that there is no ideal general solution for the problem of > rebasing merge commits. Sometimes problems aren't generically solvable. However, sometimes the problem is solvable, but folks so far have only provided solutions built on a faulty basis, or that were only designed for special cases, or that only look at a subset of the problem space. I think rebasing merges falls into the latter category, and that the prior proposals were just off the mark. Granted, I haven't implemented my proposal yet and I might discover more issues when I do, but I'm optimistic. It just really needs some good uninterrupted time, and my Git time comes in highly interrupted occasional spurts these days (and with new short-term priorities being inserted based on other things that come up on the mailing list and from elsewhere to boot). But I'll get to it one way or another.
