On Wed, Feb 2, 2022 at 2:01 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. Adding such an ability to merge-tree would be trivial -- it basically involves just two things: (1) accepting one extra argument, and (2) calling merge_incore_nonrecursive() instead of merge_incore_recursive(). However, I think forking a subprocess for every merge of a series of commits is a completely unreasonable overhead, so even if we provide such an option to merge-tree, I still want a separate plumbing-ish tool that does non-worktree/non-index replaying of commits which is not written as a driver of merge-tree. That other tool should just call merge_incore_nonrecursive() directly. And such a tool, since it should handle an arbitrary number of commits, should certainly be able to handle just one commit. From that angle, it feels like adding another mode to merge-tree would just be a partial duplication of the other tool. However, if the other tool doesn't obviate the need for this additional mode (perhaps it ends up being forced to be too porcelain-ish insteading of plumbing-ish?), or folks really just want another merge-tree mode, I'm happy to add one along with the tool I submit later. Does that sound reasonable to you, or is there something you're still objecting to that I've missed?
