Re: [PATCH] merge-tree.c: add --merge-base=<commit> option

>
> > 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.