Drew DeVault <sir@xxxxxxxxx> writes:
> Most mailing lists prefer that new patchsets and their revisions are
> placed into a new thread. Additionally, knowledge of what In-Reply-To
> means and where to find the Message-Id to fill in are domain-specific
> and confusing to new users. In the niche situations where this is called
> for, the --in-reply-to flag is sufficient.
>
> A config option, sendemail.promptInReplyTo, has been added to re-enable
> the old behavior.
We do not break existing users' habits without a good reason, and a
subjective "this is the way I prefer" is *not* a good reason.
If/when the claim "most mailing lists prefer" can be substantiated,
we'd need to devise a transition plan to flip the default over
several releases. Here is how I would envision the plan should go.
(0) Introduce sendemail.promptInReplyTo that defaults to true; this
can be done today and it would be a genuine improvement for
those who want the new behaviour, without hurting any existing
users.
(1) Substantiate the "most mailing list prefer" claim. If we
cannot, we stop here. Otherwise we would move to the next
step.
(2) Teach "git send-email" to issue a warning message when the
telling the user that the default will be flipped in some
future version of Git and optionally ask them to tell us to
stop on the mailing list, when sendemail.promptInReplyTo
configuration variable is not set.
Advertise the future flip of the default in other channels,
too.
(3) Wait for at least a few releases. Monitor the mailing list and
other channels for objections, and if it becomes clear that we
misjudged in step (1), stop the transition plan by reverting to
the state before step (2) (i.e. not to before step (0)).
(4) Flip the default and tweak the message to tell those users who
still do not have sendemail.promptInReplyTo variable set that
the default have changed, and if they want to get prompted,
they must set the variable to true. Also stop asking them to
tell us to stop---at this point we are committed and will not
go back.
(5) Waiting for several releases
(6) Remove the code to give messages for users who do not have the
configuration variable.
