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

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

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.

Ciao,
Dscho