Subject: Re: [PATCH v3 04/15] merge-tree: implement real merges

From: Junio C Hamano <[email-masked]>
Date: Wed, 02 Feb 2022 14:01:12 -0800

Elijah Newren <[email-masked]> writes:

> Yes, you are reading right.  I think the cherry-pick/rebase
> replacement actually deserves a separate command from what merges
> should use; replaying a sequence of commits just has a number of UI
> differences and abilities that I think pull it in a different
> direction.

I completely disagree.  Each individual step in a sequence of
replaying commits in order (or in reverse order) should be
scriptable as a single merge-tree that takes "apply the change to go
from A^ to A on X".  Sequencing and placing UI around it is a job
for the script that drives merge-tree.