On Thu, Apr 21, 2022 at 01:04:29PM -0700, Junio C Hamano wrote: > Alyssa Ross <hi@xxxxxxxxx> 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:
signature.asc
Description: PGP signature
