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

From: Jonathan Nieder <[email-masked]>
Date: Thu, 12 Mar 2020 16:30:40 -0700

Junio C Hamano wrote:

>           So let's scrap the "am is taken as a synonym for apply".
> It would not help the old version taken from 'next' grok a new
> configuration file that uses "apply" anyway ;-)

Agreed.  For 2.26.0, I'm happy with either

- what we currently have, where it defaults to 'merge', or
- the more conservative approach where it supports 'merge' but defaults
  to 'apply'

Accepting multiple values for forward compatibility is an optional
cherry on top: I would like us to eventually get there, but I don't
mind if it doesn't make 2.26.0, and it's probably better to give a
change like that some cooking time.  (Although I won't complain if it
does make 2.26.0. ;-))

[...]
> We may want to think of a way to strongly encourage those who are in
> charge of choosing and maintaining the versions of Git that is used
> in their organization, whose operation depends on the healthy future
> versions of Git, to run 'next' or at least 'master', to stay ahead
> of the released versions.  Some education and advocacy is needed?

It's possible we should write up some best practices somewhere in
Documentation/ about how to make running "next" go smoothly:

- have a responsive infrastructure team.  Pay attention to changes
  landing upstream and have the infra team test before the rest of
  your user population :)

- if you have a large user population, use gradual rollouts so that a
  subset of users can find problematic changes before they affect
  everyone

- fast rollbacks

- telemetry to catch regressions (in latency, for example) when people
  are too shy to report them

We can also advertise places, such as Debian experimental, that people
can get snapshots without maintaining them themselves.

Thanks,
Jonathan