git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Should sendemail.confirm default to always?

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Apr 21, 2022, 19:58 UTC
Message-ID
<220421.86tuam5hoi.gmgdl@evledraar.gmail.com>
In-Reply-To
<20220421194832.lshqkl3bogy2f2hy@eve>
On Thu, Apr 21 2022, Alyssa Ross wrote:
Show 33 quoted lines
> [[PGP Signed Part:Undecided]]
> 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).
>
> This made me remember feeling that same sense of fear when I used
> git send-email the first few times.  At some point I discovered that I
> could set sendemail.confirm to always, and then git would always prompt
> me before sending a message, and I could review the recipients list,
> edit the message if I wanted to, etc.  After that, I was happy, and
> completely forgot that that wasn't the default behaviour until having
> this conversation.
>
> So I thought it was worth asking, might it be a good idea to change the
> default, and have git always prompt before sending mail unless it's told
> otherwise?  Expert users will be able to figure out how to change this
> default if they don't like it, but novice users won't have bad first
> experiences where they accidentally send out an email before they were
> ready any more.
>
> I don't think this change would cause too much hassle for people
> expecting the current default, because the current default is for git to
> prompt *sometimes*.  So anybody who doesn't like being prompted is
> likely to have already disabled it.
>
> These git users (who are probably in the majority!) are used to having
> edit and delete buttons, so for them the idea of having to get things
> right the first time is scary enough with a preview, let alone without
> one.  I hope you can empathize.

As a regular user of it, I have it set to sendemail.confirm=always. I can see that (goes and looks) a bit over 10% of it git blame's to me, and I'd find it too scary to operate without that mode :)

Now, I'd honestly forgotten that wasn't the default mode (I set it many years ago), but I for one think that setting makes sense.

I think a patch to do that would be worth having/reviewing (hint hint!). As always the real work is updating docs, running the tests etc., digging up ML discussions to see if there's been any past arguments for/against it etc.

In this case the code change itself should be trivial (I honestly didn't look this time, but really, it's a config default...). So this seems like a perfect task for someone not too familiar with Git's codebase, but still interested in contributing :)

Previous: Alyssa RossNext: Junio C Hamano
Message 2 of 15 in “Should sendemail.confirm default to always?”
  1. Alyssa RossApr 21, 2022
  2. Ævar Arnfjörð BjarmasonApr 21, 2022
  3. Junio C HamanoApr 21, 2022
  4. Failures in t9001-send-emailAlyssa Ross, Apr 21, 2022
  5. rsbecker@nexbridge.comApr 21, 2022
  6. Alyssa RossApr 22, 2022
  7. rsbecker@nexbridge.comApr 22, 2022
  8. Johannes SixtApr 22, 2022
  9. Junio C HamanoApr 22, 2022
  10. Alyssa RossApr 22, 2022
  11. send-email: always confirm by defaultAlyssa Ross, Apr 22, 2022
  12. Ævar Arnfjörð BjarmasonApr 22, 2022
  13. Junio C HamanoApr 22, 2022
  14. Junio C HamanoApr 21, 2022
  15. Alyssa RossApr 21, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.