Hi Phillip,

On Tue, Jan 7, 2020 at 6:43 AM Phillip Wood [off-list ref] wrote:

Hi Elijah

On 24/12/2019 19:54, Elijah Newren via GitGitGadget wrote:

quoted

From: Elijah Newren <redacted>

Currently, this option doesn't do anything except error out if any
options requiring the interactive-backend are also passed.  However,
when we make the default backend configurable later in this series, this
flag will provide a way to override the config setting.

I wonder if we really want to add a new option that we know we don't
want to keep in the long term. Could we not just default to the
interactive backend and fallback to the am backend if the user passes
any of the am-based options on the commandline? i.e. reverse the current
situation of defaulting to the am backend and selecting the interactive
backend when the user passes certain options.

Good question.  For context, this option served a few purposes:
  * Providing an escape hatch during the transition in case the merge
backend doesn't handle everything the am one does in our first
attempts (i.e. similar to how we allowed using the scripted rebase
even after providing a built-in one).
  * Makes the documentation much more concise and clear (being able to
specify that various flags "imply --am" is simple, whereas removing
the flag makes me feel I need the full description of --am in each of
the few places a flag that would have implied it).
  * Provides an easy way to make the plethora of am-specific rebase
tests use the am-backend.

However, I thought of this option before Junio suggested a
rebase.backend config setting, so we could just rely on that instead.
Thus, getting rid of the "--am" flag in detail would mean:
  * I need to redo the test changes in this series to use "-c
rebase.backend=am" instead of "--am"
  * It will be slightly harder for users to use the escape hatch in
one-off cases during the transition
  * We need to figure out the right way to reword the documentation

The first two are pretty minor, so that probably means I just need to
come up with some good wording for the documentation (suggestions
welcome...)


Elijah