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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 21, 2022, 18:55 UTC
Message-ID: <xmqqee3wt5g3.fsf@gitster.g>
In-Reply-To: <CABPp-BEaemkGGm0cSofP0gau7YN-y6HFoi0yJbHA8+iGjxsYSA@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 15 quoted lines

> 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?