Re: [PATCH v2 4/8] merge-tree: implement real merges
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 11, 2022, 13:39 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2201111435430.1081@tvgsbejvaqbjf.bet>
- In-Reply-To
- <xmqqmtk78dty.fsf@gitster.g>
Hi Junio,
On Fri, 7 Jan 2022, Junio C Hamano wrote:
Show 29 quoted lines
> 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