Øyvind Rønningstad <ronningstad@xxxxxxxxx> 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.
