Hi Junio, On Mon, 21 Feb 2022, Junio C Hamano wrote: > 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". 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. > 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
