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?
