Jacob Keller <jacob.keller@xxxxxxxxx> writes: > On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov <sorganov@xxxxxxxxx> wrote: >> >> Hi Johannes, >> >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: [...] > I'm pretty sure the fact has already been accepted, as he did indeed > implement and develop a strategy for rebasing the merges (Phillip's > strategy). He hasn't chosen to re-write all the code such that it was > "always" this method, but rather kept it as an incremental patch on top as > it makes it easier to review the changes since we've already spent time > looking at and reviewing the --recreate-merges patches. That's perfectly OK with me, except that he apparently still can't accept the fact that rebasing a non-merge is not fundamentally different from rebasing a merge. "Rebase non-merge" is just a special case of generic "rebase commit", provided we do have generic method that is capable to rebase any commit, and we do have it, Phillip's or not. > Having watched from the sidelines, I've been unable to completely > understand and parse the strategies completely, but I've also found > Phillip's method to be easier to understand. It doesn't matter at all for this particular discussion. Let's call the method "rebase a commit", a black-box, that is capable to rebase any commit. I don't care what implementation is inside. Rebasing a commit is still rebasing a commit, and it should not be called "merge" in the todo list. > As someone who's read the discussion on the sidelines, it certainly > does feel like there is some misunderstanding on both sides. Neither > of you have been able to get the other to see what you clearly both > believe strongly. Calling "rebase" operation "merge" is wrong no matter what method is used to rebase a commit. Isn't it obvious? It's currently called "pick" in the todo and it seems natural to continue to use that name for picking a commit, whatever number of parents it happens to have. > Unfortunately I do not have any suggestion as to how to resolve the > misunderstanding. This sub-thread is not about method at all, so no resolution on that matter is required here. This sub-thread is about todo format only. > Sergey's method appears to me to be more complex, and I agree that the > extra steps could cause more merge conflicts, at least in how it was > originally conceptualized and implemented. It is possible that we are > mis-understanding the terminology for U1 and U2? It sure seems like it > introduces more changes for merge conflicts than the strategy proposed by > Phillip. However, the latest editions also sound a lot closer to Phillip's > strategy in general, so maybe I have mis-understood how it works and what > is fundamentally different about the two strategies. There is nothing fundamentally different between them and thus I don't care in this discussion what exact method is being used. -- Sergey
