Re: [RFC PATCH 0/2] Introduce new merge-tree-ort command

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 10, 2022, 17:56 UTC
Message-ID: <xmqq8rvn1nkw.fsf@gitster.g>
In-Reply-To: <nycvar.QRO.7.76.6.2201101427440.339@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 13 quoted lines

> I am against a new command for what essentially serves the original
> purpose of `merge-tree`.
>
> The fact that `merge-tree` has not seen any work in almost 12 years is
> testament not only to how hard it was to disentangle the work-tree
> requirement from the recursive merge (it is one of my favorite
> counterexamples when anybody claims that you can easily prototype code in
> a script and then convert it to C), but the fact that there is no user
> within Git itself (apart from t/t4300-merge-tree.sh, which does not count)
> speaks volumes about the design of that `merge-tree` tool.
>
> So it's only fair to breathe life into it by letting it do what it was
> meant to do all along.

My "Yup" would not weigh as much as one that Linus (whose original merge-tree survived this long without seeing much enhancements) might give us, but he is busy elsewhere so you guys have to live with mine ;-)

As to its output, I do agree that "we give a tree when it is already usable to record in a new commit" is a valuable option to have. The original behaviour should be made available somehow, for those who built their workflow (including scripts) around it, though.