From: Sergey Organov Date: Thu, 12 Apr 2018 05:42:27 GMT Subject: Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology Message-ID: <87sh810ym4.fsf@javad.com> In-Reply-To: Hi Jacob, Jacob Keller writes: > On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov 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: 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. > 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]: > 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 ;) ] 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: 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. -- Sergey [1] https://public-inbox.org/git/bc9f82fb-fd18-ee45-36a4-921a1381b32e@gmail.com/ [2] https://public-inbox.org/git/a3d40dca-f508-5853-89bc-1f9ab393416b@gmail.com/