Hi Sergey, On Wed, 11 Apr 2018, Sergey Organov wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Tue, 10 Apr 2018, Sergey Organov wrote: > > > >> Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > >> > >> > Once upon a time, I dreamt of an interactive rebase that would not > >> > flatten branch structure, but instead recreate the commit topology > >> > faithfully. > >> > >> [...] > >> > >> > Think of --rebase-merges as "--preserve-merges done right". > >> > >> Both option names seem to miss the primary point of the mode of > >> operation that you've formulated in the first sentence. I suggest to > >> rather call the new option in accordance to your description, say, > >> --no-flatten, --keep-topology, or --preserve-shape. > > > > A very quick A/B test shows that neither --no-flatten nor --keep-topology > > and certainly not --preserve-shape conveys to Git users what those options > > are supposed to do. > > In fact, my preference would be --[no-]flatten, exactly because the > default mode of rebase operation flattens the history, and thus what I'm > talking about is: > > git rebase --no-flatten And this is the option out of the four that fared *worst* in the A/B testing. Not even experts in Git internals were able to figure out what the heck you are talking about. Now, you can beat that dead horse until it is pulp. Your choice. I'd rather go on to more interesting things, because as far as I am concerned, the naming issue has been settled, with you being the only person in disfavor of --rebase-merges. What you *could* do is finally take your RFC to the test. Run it with the concrete example I showed you in https://public-inbox.org/git/nycvar.QRO.7.76.6.1803261405170.77@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ It is high time that you demonstrated on this concrete case study how your proposed solution performs. And then tally that up with Phillip's strategy. Ciao, Johannes
