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

From: Junio C Hamano <[email-masked]>
Date: Fri, 28 Oct 2022 09:03:50 -0700

Elijah Newren <[email-masked]> writes:

> On Thu, Oct 27, 2022 at 11:09 AM Junio C Hamano <[email-masked]> 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.