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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 22, 2022, 16:45 UTC
Message-ID: <nycvar.QRO.7.76.6.2202221730431.11118@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqee3wt5g3.fsf@gitster.g>

Hi Junio,

On Mon, 21 Feb 2022, Junio C Hamano wrote:

Show 24 quoted lines

> Elijah Newren <newren@gmail.com> 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".

Correct. The single cherry-pick will be a trivial fall-out of such a sequencer, and the opposite is not true: if we taught `merge-tree` the options `--cherry-pick` or `--revert`, the result would be a dead end because it does not make sense to extend `merge-tree` to do what the `sequencer` would do.

Show 5 quoted lines

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

But that `--rebase-merges`-like behavior is far off in the future, and the sequencer is not.

If you step back for a moment and think about the existing use cases where we want to use `merge-tree` on the server side, there are GitHub's Pull Requests (and I suspect that all other Git hosting services followed suite), where you have three options:

- merge
- squash
- rebase

The first two options are actually pretty much done, as we already have a way with the current iteration of `merge-tree` to get the tree, and that's all we need from `merge-tree`, the rest can be done by calling `commit-tree` with the appropriate parent(s) and commit messages.

In contrast, `rebase` will require not only `tree` objects to be generated, but much more. It is a fundamentally more complex operation because of that.

Now, if there were already server-side user interfaces to cherry-pick, I could potentially see that the next logical step would be to support something like the `--force-non-recursive-base=<tree-ish>` option I have already implemented over here (for separate reasons).

But I am unaware of such a user interface. I _am_ aware of the `rebase` option to apply Pull Requests. So I think that's the logical direction we're going from here.

> So why isn't your objection not equally absurd against having a
> single step cherry-pick or revert primitive as a plumbing?

Well, if you care so deeply about it, I will offer up that patch to support `--force-non-recursive-base=<tree-ish>` (where the `cherry-pick` and `revert` primitive would not need to exist but be the special case of passing `CHERRY_PICK_HEAD^` as the appropriate argument).

What gets me excited much more, though, is the `rebase` operation. And therefore I would like to spend more focus on that, and focus is a limited resource (especially here on the Git mailing list :-)).

Ciao, Dscho