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 :-) > 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? > > 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. And it still has no satisfactory simple explanation why it works. > 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! So your point is...? > > - 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. Describe why the one amended with Buga's hack works. > 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. > >> 3. I now use "True Merge" name instead of former "Trivial Merge", to > >> avoid confusion with what Git documentation calls "trivial merge", > >> thanks to Junio C Hamano <gitster@xxxxxxxxx> for pointing this out. > > > > "True Merge" is probably also a candidate for improvement. If what you > > refer to is a "true" merge, that means all others are "untrue" > > merges??? > > [d]evil merges, obviously. > > Seriously, it's pure history joint. Just "joint' will do. You might want to try harder to stick with the existing nomenclature. That would make it a lot easier to discuss. Ciao, Johannes
