Hi Jacob, Jacob Keller <jacob.keller@xxxxxxxxx> writes: > On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov <sorganov@xxxxxxxxx> wrote: >> 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 >> > > I'm going to jump in here and say that *I* prefer --rebase-merges, as > it clearly mentions merge commits (which is the thing that changes). OK, thanks, it's fair and the first argument in favor of --rebase-merges I see. I don't get why this detail matters so much it should be reflected in the option name, and if it is what matters most, why the patch series are not headed: <twisted quote> rebase -i: offer to rebase merge commits. Once upon a time, I dreamt of an interactive rebase that would not drop merge commits, but instead rebase them. </twisted quote> > I hadn't mentioned this before, because it was a suggestion that > someone else made and it seemed that Johannes liked it, so I didn't > think further discussion was worthwhile. So you guys seem to be winning 2:1, or even 3:1, counting the guy who made the suggestion. Except it was Buga's suggestion [1], and I believe I was able to convince him that something like --no-flatten would be better [2]: <quote> > I hope he'd be pleased to be able to say --no-flatten=remerge and get > back his current mode of operation, that he obviously has a good use > for. Makes sense, I like it, thanks for elaborating. [ Especially that you used "(no) flatten" phrasing, where original `--preserve-merges` documentation says it`s used "not to flatten the history", nice touch ;) ] </quote> So I assume it's 2:2 by now, with the author of original suggestion on my side. I still find git rebase --rebase-merges both being ugly and missing the point. When I look at it with a fresh eye, the questions that immediately rise are: "What the hell else could 'git _rebase_' do with (merge) commits but _rebase_ them? Why do I even need to specify this option? Should I also specify --rebase-non-merges to rebase the rest of commits?" Well, if it was called something like --[no-]keep-merges, it'd make more sense as it'd be obvious that alternative is to drop merges (notice how the old --preserve-merges does match this criteria). However, it'd still miss to reflect the generic intent of the patch series, -- to preserve history shape as much as possible, -- now citing author's head message non-twisted: <quote> rebase -i: offer to recreate commit topology Once upon a time, I dreamt of an interactive rebase that would not flatten branch structure, but instead recreate the commit topology faithfully. </quote> -- Sergey [1] https://public-inbox.org/git/bc9f82fb-fd18-ee45-36a4-921a1381b32e@xxxxxxxxx/ [2] https://public-inbox.org/git/a3d40dca-f508-5853-89bc-1f9ab393416b@xxxxxxxxx/
