Hi, Le 18/02/2020 à 17:00, Johannes Schindelin a écrit : > 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. > I do agree too, for the same reasons as Elijah expressed. Alban > Ciao, > Dscho >
