Hi Johannes, Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Hi Sergey, > > On Wed, 7 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >> > On Tue, 6 Mar 2018, Sergey Organov wrote: >> > >> >> This is v2 of my "Rebasing merges" proposal. >> > >> > Didn't we settle on Phillip's "perform successive three-way merges >> > between the original merge commit and the new tips with the old tips >> > as base" strategy? >> >> It seems you did, dunno exactly why. > > That is not true. You make it sound like I was the only one who liked > this, and not Phillip and Buga, too. > > Are you interested in the best solution, or in your solution :-) I'm interested in any that works, and only you say that those suggested by Phillip is somehow superior. I still believe it's mine that superior, even if slightly. > >> The main problem with this decision is that we still don't see how and >> when to stop for user amendment using this method. OTOH, the original >> has this issue carefully discussed. > > Why would we want to stop, unless there are merge conflicts? There is somewhat lengthy discussion about it that you probably missed. Not to repeat it, just see how 'rerere' works when it fires during rebase, even with no conflicts. > >> > It has the following advantages: >> > >> > - it is *very simple* to describe >> >> The original is as simple if not simpler: >> >> "rebase sides of the merge commit and then three-way merge them back >> using original merge commit as base" > > And that is also wrong, as I had proved already! Only Buga's addition made > it robust against dropping/modifying commits, and that addition also makes > it more complicated. No. Get your facts straight. The [RFC v2] already fixed that original mistake. Could you please finally read it? > And it still has no satisfactory simple explanation why it works. It has. It's there in the [RFC v2]. You seem to be the only one who doesn't get it. I suppose you just didn't bother to read. >> No problems with octopuses, and no virtual merge bases of recursive >> merges to reason about. > > But those are no problems for Phillip's strategy, either! I thought it was you who started to discuss virtual merge bases and related problems, as well as how it's difficult to support octopus merges, but it's fine with me if there are none of these problems. > > So your point is...? Still the same -- use what's better, the [RFC v2]. > >> > - it is *very easy* to reason about, once it is pointed out that >> > rebases and merges result in the same trees. >> >> The original is as easy to reason about, if not easier, especially as >> recursive merge strategy is not being used there in new ways. > > So do it. I still have to hear a single-sentence, clear and obvious > explanation why it works. > > And please do not describe why your original version works, because it > does not work. Original [RFC] didn't work because of rather simple mistake that I've already admitted and fixed. [RFC v2] has got the fix. Read [RFC v2] and get your facts straight. > Describe why the one amended with Buga's hack works. It doesn't matter as these hacks are not needed anymore. > >> I honestly don't see any advantages of Phillip's method over the >> original, except personal preferences. At the same time, I have no >> objection of using it either, provided consistency check problem is >> solved there as well. > > Okay, let me reiterate then, because I do not want this point to be > missed: > > Phillip's method is essentially merging the new tips into the original > merge, pretending that the new tips were not rebased but merged into > upstream. > > So it exploits the duality of the rebase and merge operation, which both > result in identical trees (potentially after resolving merge > conflicts). > > I cannot think of any such interpretation for your proposal augmented by > Buga's fix-ups. And I haven't heard any such interpretation from your > side, either. No fix-ups or augmentations are needed. It was a mistake that has been fixed in [RFC v2]. You've missed essential part of the discussion. Read the [RFC v2], please: Significant changes are: 1. Fixed mistake in the final merge step in the original proposal: wrong merge base was used. -- Sergey
