On Fri, Oct 28, 2022 at 9:03 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > 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. Ooh, the separator idea sounds like a good solution. > 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. I agree that this kind of functionality probably makes sense for inclusion from a completeness perspective, but I still maintain that if its sole purpose is implementing a cherry-pick command then it's at best an ill-advised or interim hack and we should instead do something better. While combining this patch with --stdin does solve the "single operation per invocation" issue, that's only one of six issues I listed in my email to Kyle about why this is the wrong base for building a cherry-pick alternative.
