Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

From: Sergey Organov <sorganov@gmail.com>
Date: Apr 12, 2018, 05:42 UTC
Message-ID: <87sh810ym4.fsf@javad.com>
In-Reply-To: <CA+P7+xq8KJKJ0d1unW3btUhKVjOZM3EdTSKdDs96pn5J3WwSKA@mail.gmail.com>

Hi Jacob,

Jacob Keller <jacob.keller@gmail.com> writes:

Show 10 quoted lines

> On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov <sorganov@gmail.com> 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@gmail.com/ [2] https://public-inbox.org/git/a3d40dca-f508-5853-89bc-1f9ab393416b@gmail.com/