Re: [PATCH v2 4/8] merge-tree: implement real merges

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Fri, 7 Jan 2022, Junio C Hamano wrote:

> Elijah Newren <newren@gmail.com> writes:
>
> >>    'git merge-tree' [--write-tree] <branch1> <branch2>
> >>    'git merge-tree' [--demo-trivial-merge] <base-tree> <branch1> <branch2>
> >>
> >> That way, the old mode can still function, and can even at some stage be
> >> deprecated and eventually removed.
> >
> > Ooh, interesting.
>
> I wondered if we can _also_ extend the trivial-merge mode so that we
> do not have to call it "demo".
>
> The internal result is expressed in this way:
>
>     struct merge_list {
>             struct merge_list *next;
>             struct merge_list *link;	/* other stages for this object */
>
>             unsigned int stage : 2;
>             unsigned int mode;
>             const char *path;
>             struct blob *blob;
>     };
>
> because the command was not designed to resolve content level
> merges, but show the half-resolved state with the "stage" number.
> The "explanation" the command gives on the result is truly trivial,
> but there is no reason for it to stay that way.

The original `merge-tree` code outputs a diff, which I think has now been
firmly established as something a low-level merge tool should not do at
all.

So I am not sure how necessary it is to maintain the original UI. I don't
think it is a good UI. In fact, I am rather certain that we will want to
get rid of it.

We can keep it for backwards-compatibility for now, keeping it working for
existing users (if any!) by that 3-arg vs 2-arg trick, eventually
deprecate and then remove it.

Ciao,
Dscho