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

[Junio C Hamano <gitster@pobox.com>]

Drew DeVault <sir@cmpwn.com> 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.