Re: en/rebase-backend, was Re: What's cooking in git.git (Feb 2020, #04; Mon, 17)

> Hi Elijah,
> 
> On Mon, 17 Feb 2020, Elijah Newren wrote:
> 
>> On Mon, Feb 17, 2020 at 2:09 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> * en/rebase-backend (2020-02-16) 20 commits
>>>  - rebase: rename the two primary rebase backends
>>>  - rebase: change the default backend from "am" to "merge"
>>>  - rebase: make the backend configurable via config setting
>>>  - rebase tests: repeat some tests using the merge backend instead of am
>>>  - rebase tests: mark tests specific to the am-backend with --am
>>>  - rebase: drop '-i' from the reflog for interactive-based rebases
>>>  - git-prompt: change the prompt for interactive-based rebases
>>>  - rebase: add an --am option
>>>  - rebase: move incompatibility checks between backend options a bit earlier
>>>  - git-rebase.txt: add more details about behavioral differences of backends
>>>  - rebase: allow more types of rebases to fast-forward
>>>  - t3432: make these tests work with either am or merge backends
>>>  - rebase: fix handling of restrict_revision
>>>  - rebase: make sure to pass along the quiet flag to the sequencer
>>>  - rebase, sequencer: remove the broken GIT_QUIET handling
>>>  - t3406: simplify an already simple test
>>>  - rebase (interactive-backend): fix handling of commits that become empty
>>>  - rebase (interactive-backend): make --keep-empty the default
>>>  - t3404: directly test the behavior of interest
>>>  - git-rebase.txt: update description of --allow-empty-message
>>>
>>>  "git rebase" has learned to use the sequencer backend by default,
>>>  while allowing "--am" option to go back to the traditional "am"
>>>  backend.
>>>
>>>  The last step may be rushing things a bit and may want to be
>>>  taken separately.
>>>  cf. <pull.679.v5.git.git.1581802602.gitgitgadget@gmail.com>
>>
>> Thanks.  I'm curious, though, what you mean by this last bit -- was it
>> just a reflection of my request for folks to comment on whether the
>> last patch was wanted?
>>
>> In my view, taking the last patch separately does not make sense; it
>> should either be dropped entirely or taken close to the same time as
>> the series.  My reasoning for this is as follows: The only place the
>> current backend names exist is in the documentation.  The cost of
>> changing the names is thus low.  Once this series lands, the backend
>> names will be exposed in the user interface.  If we cut a release with
>> those names, then changing the names will require a bunch of
>> transition work.  So, if we're going to change the backend names, it'd
>> be better to do it sooner (while the cost is negligible) rather than
>> later.
>>
>> So far, Phillip has voiced an opinion on this (cf.
>> <e2863381-174c-a55c-bb22-0c7aec9cabf4@gmail.com>) -- "I think it is a
>> good idea - merge and apply make much more sense that interactive and
>> am"; haven't heard from anyone else yet.
> 
> FWIW I am also in favor of renaming the backends. Unfortunately, I won't
> have time to review this patch series for the foreseeable time.
>