Hi Buga, On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> On 12/03/2018 11:20, Johannes Schindelin wrote: > > > > > > [...] and cannot introduce ambiguities when rebasing the > > > > changes introduced by M (i.e. the "amendmendts" we talked about). > > > > > > Hmm, not following here, which ambiguities are we talking about? > > > > U1' vs U2' of course. Those are two things that can be different, even if > > they ideally would have identical trees. > > > > Phillip's strategy does not leave that room for ambiguity. > > Ehm, in Sergey`s approach, this is not an issue, but a feature :) Well, in my use cases, this would not be a good feature. It would be highly annoying, confusing, and cost me tons of time. > If U1' != U2', it just means a more complex rebase happened, but it > doesn`t compromise the result (rebased merge) in any way. No, it just means that your strategy failed to give a consistent answer to the question "what would the rebased merge commit's tree look like". > On the other hand, if U1' == U2', we can be pretty sure that merge > rebasing went as clean as possible. With the backsplanation I gave for Phillip's strategy, I can be as sure that rebasing went as clean as possible if it does not produce merge conflicts: it reconciles the changes introduced by 1) rebasing the merge tips with the changes introduced by 2) the original merge commit relative to its parents. And even if it produces merge conflicts, I know at least that those are conflicts between those two sets of changes. Ciao, Dscho
