Re: Should sendemail.confirm default to always?

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]

On Thu, Apr 21, 2022 at 01:04:29PM -0700, Junio C Hamano wrote:
> 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.

In all the time I've been using sendemail.confirm = always, I've never
accidentally said "yes".  I'd be curious whether Ævar has, since they
also said they've used it for some time.

I think always confirming is better than --dry-run because it allows
making a decision for each message in a series, and because it makes it
easy to insert commentary.  (If you end up sending the first few
messages in a series, then deciding not to send the rest before fixing
something, the man page is good enough that it's possible to figure out
how to resume sending, in my experience.)

If you had to pass --no-dry-run every time, I'd worry about that being
replayed unthinkingly from shell history, defeating the purpose.  By
contrast, interactive per-message confirmation won't end up with the
bypass being automatically saved in shell history.

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

I thought about that, but I don't think it would be as good either,
because it's difficult to predict what the final set of recipients will
be just from looking at the patch files — if I recall correctly,
automatic CCs (from trailers, cccmd, etc.) aren't added until send-email
time.  So even though I often run format-patch beforehand, I'm still
grateful to be prompted before each message.

I also think that encouraging novices to format-patch first would make
the workflow seem even more arcane and confusing.  I definitely found it
very strange the first time I encountered it (more so than all-in-one
send-email).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]