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

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

Elijah Newren wrote:

quoted

On Thu, Mar 12, 2020 at 8:13 AM Emily Shaffer [off-list ref] wrote:

quoted

quoted

This broke quite a few upstream users for us today when we rolled out a
next with this patch added on top. To shim around the post-commit hook
issue, we had set a system config for all our users to use
merge.backend=am; the machinery is pretty intolerant to a wrongly
configured backend name (die() rather than a warning and fallback).

Would it make more sense to deal with an unrecognized backend by falling
back to the default backend, instead?

[...]

quoted

Sorry for the pain.  The earlier part of the series had only ever made
it to next, and was reverted there, and thus, in my thinking, in the
new cycle no one would have ever seen the intermediate state.  (Oops,
I forgot about cases where people tried out next towards the end of
last cycle before it was reverted and decided to set config based upon
it.)

Right, I'm mostly interested in this for the future: do we expect the
list of backends to only grow over time, or do we want to support
removing and renaming backends?  In the latter case, how can we support
people sharing config between multiple Git versions with their
merge.backend settings?

Good questions.  We have already stated that backends might be
"removed" or at least "ignored"; from Documentation/config/rebase.txt:

rebase.backend::
        Default backend to use for rebasing.  Possible choices are
        'apply' or 'merge'.  In the future, if the merge backend gains
        all remaining capabilities of the apply backend, this setting
        may become unused.

In other words, we're already telling users that 'apply' might mean
'merge' in future versions of git.  (Or at least that was my mental
model; perhaps I should tighten up the wording to state it that way?)

I hadn't thought in terms of adding backends, especially since we've
been trying to remove them, though given our history[1] maybe I should
have.  I guess it's possible we could introduce another backend[2],
though we don't necessarily have to make it possible to configure
every backend as the default.  For example, despite the technical
existence of another backend right now, I did not make
'preserve-merges' a possible setting since it is already deprecated.
(And to go on a bit of a tangent, I think that if someone is not in
the middle of a rebase and tries to start one with the -p flag, we
should just throw a warning and pretend they passed -r.  We should
kill preserve-merges as much as possible.  Anyway, enough of that
tangent...)

[1] By my count, we've had at least five rebase backends: apply/am,
merge-via-shell-out-to-merge-recursive-builtin,
legacy-interactive-via-shell,
interactive-as-builtin-and-now-called-merge, and preserve-merges.  I
think at one point all five co-existed.  And I wouldn't be surprised
if I've forgotten, overlooked, or otherwise missed others.

[2] Maybe I even started one with
https://github.com/newren/git/blob/git-merge-2020-demo/builtin/fast-rebase.c,
but unless it's just too hard to refactor sequencer.c &
builtin/rebase.c to make use of merge-ort (AND quit forking
subprocesses other than with --exec and -s AND avoid writing state
files unless and until you hit a conflict), I'm thinking that dies as
nothing more than a demo.

quoted

I'm a little worried about ignoring the setting and just picking one;
if the setting has been marked and they set it to e.g. "appply" (one
too many p's), then does it really make sense to just show a warning
but continue using the backend they didn't want, especially since they
may miss the warning among the rest of the output?  I'd rather go the
route of improving the message, perhaps:
        _("Unknown rebase.backend config setting: %s")
Would that work for you?

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?  ('merge' and 'apply' are recognized values.
If no value is specified, the default of merge is used.  If values are
specified but none are recognized, it errors out.)  Would my suggested
change above fix it so that we can consider it sufficiently clear, or
do you want something else?

quoted

Also, I thought that you and Jonathan were going to be changing the
post-commit hook handling[1][2].  Does this mean that you've punted on
that, and I need to make some kind of change here to get you to switch
over?

The setting was a stopgap; our interest in this upstream is primarily
from the point of view of "we ran into this, so let's take the
opportunity to help others that might run into similar issues in the
future".

Thanks for flagging it; I appreciate it.  Is my suggested rewording of
the error message helpful?  Have I missed or misunderstood anything
else you were trying to bring up?