Re: Should sendemail.confirm default to always?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2022, 20:04 UTC
Message-ID: <xmqq8rrygq42.fsf@gitster.g>
In-Reply-To: <20220421194832.lshqkl3bogy2f2hy@eve>

Alyssa Ross <hi@alyssa.is> writes:

Show 7 quoted lines

> 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.