Re: Should sendemail.confirm default to always?

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

Alyssa Ross <hi@alyssa.is> writes:

> I was recently having a conversation with some people used to the
> GitHub-style Pull Request workflow, who told me that they feel scared of
> using git send-email in case they make a mistake and e.g. get the
> recipients wrong, since they can't correct it after sending.  They can
> resend, but if they do that they'll feel like they're bothering some
> very busy people by having sent them the same message twice (regardless
> of whether those people are actually bothered by it, it's scary).

If it truly makes sense to give a roadblock before sending to
prevent mistakes, I wonder if making "--dry-run" the default is even
a better idea.  Getting "are you sure [y/n]?" and saying "yes" out
of inertia is much more likely to happen than typing Ctrl-P on the
command line to take the previous command (which did a dry-run by
default) back on the command line and then adding "--no-dry-run" on
the command line to allow the command to actually send out the
files.

Another idea is to forbid the form of "git send-email" invocation
that internally runs format-patch by default and force users to
prepare format-patch into files beforehand.  Doing the format-patch
as a completely separate step means that the user has a final chance
to proofread the log messages (and correct them as needed) while
adding and verifying CC's, and removes the pressure of "pressing
this button is a point of no return; did I catch all the
embarrassing mistakes?" at the last second.