Hi Johannes, Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: [...] > The biggest difference is that it is easy for me to see the motivation > behind Phillip's strategy, whereas I am still puzzled why one would come > up with a complicated strategy that splits merge commits and re-merges > them later, and why it should work in general (I still suspect that this > is not the case). Because I believe that rebasing simple commit (1 parent) should be nothing else but reduced version of rebasing any commit (N parents) at N=1. The [RFC v2] being discussed provides exactly such a method. OTOH, check what Phillip's version does at N=1. Is it the same as "rebase simple commit" strategy you already happily use? If not, please explain why it must be different. > 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]_. > But I'll take your word for it that the strategies are equivalent, and go > with the one that has both a simpler explanation (in my mind, at least), > and an more robust implementation. It's up to you, and it'd still be much better than what we have now, but you will need to face the (I think unfortunate) consequences I just summarized elsewhere in the thread. -- Sergey
