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

From: Elijah Newren <newren@gmail.com>
Date: Oct 28, 2022, 08:20 UTC
Message-ID: <CABPp-BHceBeo6Y8s00gET=4yqCMf3qqsiNMhqJ34HVf8r=bhnw@mail.gmail.com>
In-Reply-To: <xmqqczadm93w.fsf@gitster.g>

On Thu, Oct 27, 2022 at 11:09 AM Junio C Hamano <gitster@pobox.com> wrote:

[...]

Show 12 quoted lines

> 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^ ?

Show 6 quoted lines

> 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?)