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 don't like this solution. We should make it harder to do the wrong thing, and easier to do the right thing. It would be helpful for git to take an opinionated stance on the right way to send emails with it, since no one else is really in the position to. This behavior has confused many people that I've spoken with and makes for a rough introduction to a tool which people are already loathe to learn. git send-email is really the best way to send emails with git, and will save the user a lot of trouble in the future if they figure it out, so I want it to be as easy to figure out as possible. Even so, I understand the concerns raised so far. I haven't started on v2 yet, but my rough plan is to add a config option along the lines of sendemail.verbosePrompts, defaulted to on for now, which enables the present-day behavior, along with a message stating the intention to change the behavior in a future release, and an invitation to comment on the mailing list. The behavior of this flag if set to false would be equivalent to removing the $prompting condition in the if statement which controls whether or not this prompt is shown.
