Dear Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> Hi Sergey, > > On Mon, 12 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > [...] >> > >> > Where "easy" meant that I had to spend 1h still to figure out why >> > using the unrebased merge parents as merge bases. >> >> That's because you try to figure out something that is not there in the >> [RFC v2]. I suggest to forget everything you've already imagined and >> just read the [RFC v2] proposal afresh. It should take about 10 minutes >> or less to get it. Really. >> >> > The same amount of time did not allow me to wrap my head around >> > Sergey's verbose explanations. >> >> Honestly, I don't believe it, sorry, but I'm willing to explain anything >> you wish to be explained in _[RFC v2]_. > > No, really. If you cannot bring yourself to believe my words, then I hate > to break it to you: I am not lying. > > As to "I'm willing to explain anything you wish to be explained in RFC > v2": I was asking, and asking, and asking again, for a simple summary of > the idea behind your proposal. Nothing. That was the answer. No. The answer rather was this simple explanation that I gave you multiple times already "rebase each side of the merge, then merge the results back using original merge commit as the merge base". Yet you say there was none. I'm confused. Well, as it seems you grok Phillip's notation just fine, here is RFC algorithm in this notation [1]: git checkout --detach A' git merge-recursive A -- A' M tree_U1'=$(git write-tree) git checkout --detach B' git merge-recursive B -- B' M tree_U2'=$(git write-tree) git merge-recursive M -- $tree_U1' $tree_U2' tree=$(git write-tree) M'=$(git log --pretty=%B -1 M | git commit-tree -pA' -pB') > I had to figure it out myself: the idea is to *create* fake commits, > non-merge ones, for every single merge commit parent. Those fake commits > combine the changes of *all* merge commit parents *but one*. And then > those commits are rebased, individually, with tons of opportunities for > merge conflicts. Repeated ones. And then that result is merged. Wrong. See above. Anyway, it doesn't matter anymore, see [1]. References: [1] https://public-inbox.org/git/87efkn6s1h....@javad.com -- Sergey
