Elijah Newren <newren@xxxxxxxxx> writes: > On Thu, Oct 27, 2022 at 11:09 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> > [...] >> Wouldn't it be sufficient to update the UI to >> >> git merge-tree [--write-tree] [<options>] [<base-commit>] <branch1> <branch2> >> git merge-tree [--trivial-merge] <base-commit> <branch1> <branch2> >> >> IOW, when you want to supply the base, you'd be explicit and ask for >> the new "write-tree" mode, i.e. >> >> $ git merge-tree --write-tree $(git merge-base branch^ branch) HEAD branch >> >> would be how you would use merge-tree to cherry-pick the commit at >> the tip of the branch on top of the current commit. > > This was my thought too; but would we be painting ourselves into a > corner if we ever want to make merge-tree support octopus merges? True, the above suggestion was especially bad as it would not be possible to extend to support multiple bases *and* octopus at the same time. Consider it scrapped. Taking zero or more --base-commit options explicitly from the command line would be a better interface. > Also, why did you write $(git merge-base branch^ branch) rather than > just branch^ ? Just to be explicit which one is doing what. > Yeah, I don't think that'd be too hard...if we could rule out ever > supporting octopus merges in merge-tree (which I'm not so sure is a > good assumption). Otherwise, we might need to figure out the > appropriate backward-compatible input parsing (and output format > changes?) I'd prefer an approach to tackle one thing at a time while making sure we leave the door open for the future ones. I think the backend interface from "merge" to external strategies use a separator to signal the boundary between the heads being merged (i.e. branchN above) and the bases being used, which is easy to parse and support multiple bases and octopus at the same time. As to making it easy to implement "cherry-pick", I do not think you should dogmatically forbid it on the basis for merge-tree from the command line is inherently one mergy operation per invocation. You will have the --stdin interface, and a way forward may be a notation to refer to previous results in the --stdin input stream. That way, a single invocation of merge-tree "server" can be fed a sequence of 3-way merges that are actually steps of multi-commit cherry-pick, that merge the differences of multiple commits on top of the previous result, one step at a time. IOW, as long as you make sure --stdin interface is rich enough to allow you do what people would do a sequence of "git merge-tree" single shot invocations (perhaps even driven by a script), you would be OK, I would think.
