On Wed, Jan 12, 2022 at 10:08 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> 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.
