Elijah Newren <newren@xxxxxxxxx> writes:
> The objection you are arguing against is not my position. In fact,
> I'm not even objecting to having a single-step cherry-pick, I'm
> objecting to providing it _now_, which I thought would have been clear
> from the portion of my email you snipped ("...I'm happy to add [a
> single step cherry-pick primitive] along with the tool I submit
> later...").
The entry point into the in-core merge machinery of ort already
knows how to accept externally defined merge-base(s) to bypass the
"caller didn't give us the merge base, so let's figure them out by
using the two heads being merged" logic, so it just felt backwards
*not* to have a vanilla three-way merge that can take three trees
and be used for merge, cherry-pick or revert as the single primitive
in the very beginning before we talk about multi-step operations.
So, I guess I am still not getting where the "I'm happy to _add_"
part comes from. If we start with a primitive (internally callable
from C) "here are three trees O A B, do the three-way merge", then
there is nothing to "add" at all to expose a single-step
cherry-pick. In fact, to the users of merge-tree, the result does
not have to have any fixed meaning. If they pass common ancestors
as the merge bases as Os and the current HEAD and the other branch
as A and B, they get a merge. If they pass the commit to be picked
as B, current HEAD as A and B's parent as O, they get a cherry-pick.
Perhaps starting from "You are allowed to give me two commits A B,
and I do not let you specify the commit O to use as a common
'ancestor'" is the root cause of making this thing feel backwards.
I agree with the goal of having an all-incore machinery that can do
a merge. I just do not see the reason why you have to build it in a
way that cannot be reused for other two directions of merge-y
operations.
