On Thu, Mar 12, 2020 at 11:46 AM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
>
> Elijah Newren wrote:
> > On Thu, Mar 12, 2020 at 10:55 AM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
>
> >> 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?
