Hi Elijah, On Mon, 17 Feb 2020, Elijah Newren wrote: > On Mon, Feb 17, 2020 at 2:09 PM Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxx> > > 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@xxxxxxxxx>) -- "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
