Hi Johannes, Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Hi Sergey, > [...] >> >> Reusing existing concepts where possible doesn`t have this problem. >> > >> > Existing concepts are great. As long as they fit the requirements of >> > the new scenarios. In this case, `pick` does *not* fit the requirement >> > of "rebase a merge commit". >> >> It does, provided you use suitable syntax. > > You know what `pick` would also do, provided you use suitable syntax? Pick > your nose. > > Don't blame me for this ridiculous turn the discussion took. > > Of course, using the suitable syntax you can do anything. Unless there is > *already* a syntax and you cannot break it for backwards-compatibility > reasons, as is the case here. Backward compatibility to what? To a broken '--preserve-merges'? I had a feel you've invented '--recreate-merges' exactly to break that compatibility. No? Or is it "Backwards compatibility of a feature that existed only as a topic branch in `next` before being worked on more?", as you say yourself below? [...] >> > The implementation detail is, of course, that I will introduce this with >> > the technically-simpler strategy: always recreating merge commits with the >> > recursive strategy. A follow-up patch series will add support for rebasing >> > merge commits, and then use it by default. >> >> Switching to use it by default would be backward incompatible again? Yet >> another option to obsolete? Sigh. > > Oh wow. > > Backwards compatibility of a feature that existed only as a topic branch > in `next` before being worked on more? Any other splendid ideas? Either you care about compatibility or not. You can't have it both ways, sorry. And "technically-simpler strategy: always recreating merge commits with the recursive strategy" vs. "rebasing merge commits" is not just a minor strategy change, it's entire paradigm shift in handling merge commits while rebasing. I'm afraid you will still come up with a wrong design unless you finally accept this fact. -- Sergey
