Re: [PATCH] send-email: do not prompt for In-Reply-To

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 28, 2020, 01:02 UTC
Message-ID: <xmqqsgc7oa5s.fsf@gitster.c.googlers.com>
In-Reply-To: <C585M18ZSR87.2CMIKK2VKMC1S@homura>

"Drew DeVault" <sir@cmpwn.com> writes:

> Oh, and I should mention the fact that this breaking change is less
> severe than we initially thought, only breaking an edge case - when --to
> is not specified - so it's likely to have a pretty small impact. We'll
> find out when someone emails us to complain, I suppose.

I agree that it is likely that only very small population even gets bittn by this "in-reply-to gets prompted" issue, because it is unlikely for users not to give "to:" address in one way or another and let the prompt logic to ask them.

Which means that it is OK to stop at step (0) in the long transition sequence I outlined in a previous message from me.

That is, introduce a configuration variable that can be set to 'no' by those who do not want to be prompted for "in-reply-to:" when they did not give "to:" and let the prompt logic to ask "to:", document the variable well [*1*], and make sure the default behaviour when the variable is not set is the same as now.

That way, we do not even need to debate if it is true that most users do not want in-reply-to (i.e. step (1)). That's the kind of thing that is very hard to establish.

The minority who wants to use an updated behaviour can just set the configuration once and the problem is behind them. The minority who wants to keep the current behaviour do not have to do anything. And there is no impact to the majority of people either way.

I hate having to go through a multi cycle compatibility-breaking transition, because it would consume unnecessary resources from this list (i.e. developer attention is the most scarce common resource that must be shared across topics here), and we would avoid that cost altogether because the affected population seems to be small enough that it is not worth going through the rigmarole of flipping the default. That alone is a big plus.

It seems like we managed to cut down the scope quite a bit.

Thanks.

[Footnote]

*1* As a part of "document the variable well", we can include a message tweak for the prompt that asks for "in-reply-to:" to say something like "if you never want to be prompted for in-reply-to:, you can set this variable" when the variable is not set at all. Those who did set the variable but still are getting the prompt are explicitly opting into keeping the current behaviour by setting it to 'yes', so they do not have to see that extra part of the message.