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

[Elijah Newren <newren@gmail.com>]

On Wed, Jan 12, 2022 at 10:08 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> >> so it may be quite simple to deprecate "merge -s recursive".
> >
> > Yes...but why deprecate?  I thought the plan was to (eventually) make
> > requests for either `recursive` or `ort` be handled by running the
> > `ort` backend.  Making that kind of switch is much smaller than the
> > one we already made to switch the default backend from `recursive` to
> > `ort`, so I'm not sure I see what we gain by doing such a switch in
> > stages.  Maybe I'm missing something?
>
> Didn't we "deprecate" but still indefinitely support "annotate"?  I
> have been assuming that recursive will be in that category after ort
> establishes itself.

But in that case, we suggested folks use "blame" instead of "annotate", right?

From a user point of view, my intention was that "ort" is just the
newer version of "recursive" (which happens to be an essentially total
rewrite).  ort only got a separate name because we wanted a special
testing period and a way for users to select the old version of
recursive or the new version of recursive.  Of course, that period is
multiple release cycles, so both names will persist, but they'll just
be aliases.

Once we switch "recursive" to mean "ort" so they both run the exact
same code, I was intending to have the documentation prefer the term
"recursive" over "ort" since it is a more meaningful user-facing name.