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

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

Hi Junio,

On Mon, 10 Jan 2022, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > 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.

No, I don't think it is a good idea to keep the original behavior around
indefinitely, when it is totally unclear whether there actually _is_ any
user of this feature out there.

We intentionally broke any existing users of `git-parse-remote.sh` by
removing it, when that feature was much more likely to be used in scripts
than `git merge-tree`. We cannot say on the one hand that we will get rid
of some useful script just because we don't want the maintenance burden
when on the other hand trying to keep support for an operation that is
unlikely to have any users. That does not compute. (And don't get hung up
on the specific example of `git-parse-remote.sh`, you know there we
shuffled around _many_ more things recently that had a good chance of
breaking existing users.)

Besides, the original `git remote-tree` behavior will be very easy to
recreate using the better UI, the one that outputs tree OIDs.

Ciao,
Dscho