Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> Hi Sergey, > > 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. 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. > 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" No problems with octopuses, and no virtual merge bases of recursive merges to reason about. > - 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. 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. > > ... and BTW... > >> 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 <gits...@pobox.com> 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. -- Sergey
