Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > 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. It was you who introduced the "flatten" term, not me. I took it from your descriptions. So they are able to make sense of your own: >>> Once upon a time, I dreamt of an interactive rebase that would not >>> flatten branch structure, but instead recreate the commit topology >>> faithfully. Yet they can't get: --no-flatten:: Instead of flattening branch structure, recreate the commit topology faithfully Are you kidding? Well, suppose for a moment that nobody could even guess what "flatten" means indeed. Then are you willing to remove the "flatten" from both the description of our patch series and from the proposed patch to the Git manual: -r:: --rebase-merges[=(rebase-cousins|no-rebase-cousins)]:: Rebase merge commits instead of _flattening_ the history by replaying merges. ??? > > 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. It was rather --recreate-merges just a few weeks ago, and I've seen nobody actually commented either in favor or against the --rebase-merges. git rebase --rebase-merges _is_ plain simple ugly. > > 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. What you could do is to stop shifting the subject of discussion. The RFC v2 and Phillip's strategy are essentially the same, as has been already shown multiple times, both theoretically and by testing. Ask Bugga for details. One way or another, this doesn't make git rebase --rebase-merges even a bit less ugly. -- Sergey
