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

[Elijah Newren <newren@gmail.com>]

On Fri, Oct 28, 2022 at 9:03 AM Junio C Hamano <gitster@pobox.com> 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.