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? Also, why did you write $(git merge-base branch^ branch) rather than just branch^ ? > I also have to wonder how this should interact with a topic that is > in-flight to feed multiple merge-tree requests from the standard > input to have a single process perform multiple (not necessarily > related) merges. Elijah knows much better, but my gut feeling is > that it shouldn't be hard to allow feeding an extra commit on the > same line to be used as the base. 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?)
