Hi Jake, Jacob Keller <jacob.keller@xxxxxxxxx> writes: > On Fri, Feb 16, 2018 at 5:08 AM, Sergey Organov <sorganov@xxxxxxxxx> wrote: >> Hi, >> >> By accepting the challenges raised in recent discussion of advanced >> support for history rebasing and editing in Git, I hopefully figured out >> a clean and elegant method of rebasing merges that I think is "The Right >> Way (TM)" to perform this so far troublesome operation. ["(TM)" here has >> second meaning: a "Trivial Merge (TM)", see below.] >> >> Let me begin by outlining the method in git terms, and special thanks >> here must go to "Johannes Sixt" <j6t@xxxxxxxx> for his original bright >> idea to use "cherry-pick -m1" to rebase merge commits. >> >> End of preface -- here we go. >> > > I hope to take a more detailed look at this, also possibly with some > attempts at re-creating the process by hand to see it in practice. Thank you for your interest and for the review, and yes, some testing is what the idea desperately needs. Unfortunately I don't have much time for it right now, nor am I fluent enough in git internals to actually make even a raw prototype really soon, sorry. Anybody who is interested is very welcome to volunteer! [...] > > This might be a bit tricky for a user to understand what the process > is, especially if they don't understand how it's creating special U1' > and U2' commits. However, it *is* the cleanest method I've either seen > or thought of for presenting the conflict to the user. > [...] >> - it appears shiny to the point that it will likely be able to handle >> even darkest evil merges nicely, no special treatment required. >> > > Yep, and I like that it has a pretty reasonable way of presenting > conflicts for resolution. It may be a bit tricky to explain the use of > the intermittent commits U1' and U2' though. Yeah, I see how all this sends somewhat unique challenges to the implementation to get user interaction in case of conflicts right, even though all the basic concepts are old buddies and should be familiar to the user. That said, the recursive merge strategy comes to mind, where creating virtual merge base may itself cause conflicts, so something similar enough is likely to already exist. -- Sergey
