Elijah Newren <newren@xxxxxxxxx> writes: > 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. The above does not make much sense to me. I am hearing that "multi-step cherry-picks and reverts need to be fast and we need something like sequencer that is all written in C, and single-step cherry-pick is merely a special case that does not deserve a plumbing". But that argument leads to "and the same something-like-sequencer that is all written in C would need '--rebase-merges' that can pick multi-step merge sequences, and single-step merge does not deserve a plumbing", which is an argument against this topic that is utterly absurd. So why isn't your objection not equally absurd against having a single step cherry-pick or revert primitive as a plumbing?
