From: Junio C Hamano Date: Wed, 07 Feb 2018 23:31:20 GMT Subject: Re: [PATCH 5/8] rebase: introduce the --recreate-merges option Message-ID: In-Reply-To: <1518044326.7000.4.camel@gmail.com> Øyvind Rønningstad writes: >> 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.