Elijah Newren <newren@xxxxxxxxx> 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.
