Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 7, 2018, 23:31 UTC
Message-ID: <xmqqpo5g5qd3.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <1518044326.7000.4.camel@gmail.com>

Øyvind Rønningstad <ronningstad@gmail.com> writes:

Show 5 quoted lines

>> So no, I do not think that --recreate-merges --first-parent is a good
> idea
>> at all. Unless you try to do that non-interactively only, *and
> disallow it
>> in interactive mode*.

Correct. If the original side branch has commits A, B and C, you are rebuilding the topic to have only A and C but not B and then recreate the merge of that rebuilt topic, then you absolutely do not want "cherry-pick -m1" of the original merge when recreating the merge, as that would resurrect the effect of having B. The same argument applies if you rebuilt the topic with A and C and then a new commit D. "cherry-pick -m1" of the original would do a wrong thing.

When there is no such fixing up, "cherry-pick -m1" is the right thing to do, though, so it probably makes sense to pick merges that way when the side topic being merged consists of the same commits as the original. I do not think that the code structure in the topic as posted makes it impossible (or unnecessarily hard) to give an enhancement like that in the future as a follow-up series.