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

["Drew DeVault" <sir@cmpwn.com>]

On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote:
> To help those who do not want to add this header, it would probably
> be more helpful to tell what to do when prompted (like "you can give
> an empty answer to tell the command that you are not responding to
> any message").

I'm trying to come up with a message like this for a reduced-scope
initial patch, but I'm drawing up a blank when the goal is to avoid
confusing users who don't understand this. The goal is to remove
domain-specific knowledge about email, namely how the In-Reply-To and
Message-Id headers work, which is uncommon knowledge among new users.

"You can give an empty answer if you are not responding to any message"
could confuse users, because they might think -v2 is a "response", or
maybe they've written the patch in response to a discussion on the
-users mailing list, or any other number of reasons. Now they have to
figure out how to answer this prompt, even if the mailing list they're
sending it to isn't expecting it to be a reply. I came up with a number
of alternative wordings but they all ultimately failed to this same
problem.

In-Reply-To is such an arcane and tangental piece of knowledge so far
removed from git, and so little information is given to the user to help
them understand (1) what it is, and (2) whether they need it or not, and
(3) where to find it, that this prompt just seems totally awful to me.
It'd be like if we prompted someone to enter their display EDID when
filing a bug for a video game. Could it be useful? It's unlikely. Is the
user likely to know what the hell an EDID is? Almost certainly not!

"Legitimate" use-cases like qemu-devel or not, this is only ever going
to confuse new users, and I think that qemu is wrong for encouraging
users to deal with it.

Or they would be wrong, but I looked into it and, the qemu wiki advises
that the user does *not* use in-reply-to:

https://wiki.qemu.org/Contribute/SubmitAPatch

Nor does patchew make it easy to extract the message ID from their
interface for this use-case. I'm not sure where this qemu idea is coming
from.

Is compatibility-breaking migrations a nightmare? Well, maybe.

Is that nightmare worth such a trivial problem? Well, it seems trivial
to those of us who have been using it for years, but I can assure you
there are plenty of new users who shut down at this step.

I hate to be a nuisance over such a seemingly simple problem, but there
are a lot of new users who are struggling here and I care about their
struggle. What path should we take to fixing this issue for them?