Re: [PATCH v5 20/20] rebase: rename the two primary rebase backends

On Thu, Mar 12, 2020 at 11:46 AM Jonathan Nieder [off-list ref] wrote:

Elijah Newren wrote:

quoted

On Thu, Mar 12, 2020 at 10:55 AM Jonathan Nieder [off-list ref] wrote:

quoted

quoted

What if we support multiple merge.backend values, with semantics:

- last recognized value wins
- if no value is specified, use the default
- if values are specified but none are recognized, error out with a
  clear error message

?

Sure, but...isn't that what we already do, other than maybe the
'clear' part of step 3?

Sorry for the lack of clarity.  I mean allowing

        [rebase]
                backend = am
                backend = apply
                backend = futuristic

with behavior

- on "git" that understands am but not apply or futuristic, use the am
  backend
- on "git" that understands apply but not am or futuristic, use the
  apply backend
- on "git" that understands apply and futuristic, use the futuristic
  backend

That way, a single config file is usable on all three versions of Git.

Ah, gotcha, that makes sense though we'd need to make the thing
multi-valued which is a bit late for 2.26.  But we could at least
extend the logic in that way for 2.27.  Also, to further clarify, if
they have

         [rebase]
                 backend = misspelled
                 backend = futuristic

then what should the error be?  A couple possibilities:

fatal: Unknown rebase backend: futuristic

fatal: Unknown rebase.backend config setting: futuristic

fatal: Unknown rebase.backend config setting; valid values are 'merge', 'apply'.

or should it be something else?