On Sun Apr 11, 2021 at 11:06 AM EDT, Ævar Arnfjörð Bjarmason wrote:

3. While I'm very much leaning to #1 being a good idea, I'm very much
leaning towards introducing this "starttls" alias being a bad idea
for the same reason.
    
i.e. let's not create a new 'starttls' if we can avoid it explicitly
because we used to have the long-standing "anything unrecognized is
empty == no encryption" behavior.

A lot of users read documentation for the latest version online, but
may have an older version installed.

I feel quite strongly that the options here are a grave failure of
usability, and that it needs to be corrected. I help people troubleshoot
git send-email problems quite often, and this is a recurring error.
However, you make a good point in that someone might see some online
documentation which does not match their git version and end up with a
surprisingly unencrypted connection.

As a compromise, let's consider making this a gradual change. We can
start by clarifying the docs and forbiding the use of any value other
than 'ssl' or 'tls'. If an unknown value is set, the user is not getting
the encryption they expected anyway, and this should cause an error.

Then we can leave the issue aside for some agreed upon period of time to
allow the change to proliferate in the ecosystem, and then revisit this
at some point in the future to rename the options to make more sense.

Does this seem like a reasonable compromise?