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

Re: [PATCH] send-email: do not prompt for In-Reply-To

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 27, 2020, 22:57 UTC
Message-ID
<xmqqd03bpuh7.fsf@gitster.c.googlers.com>
In-Reply-To
<20200827220249.GA71190@Carlos-MBP>
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
Show 13 quoted lines
> On Thu, Aug 27, 2020 at 12:34:02PM -0700, Junio C Hamano wrote:
>> 
>> That feels both understandable and bogus at the same time.  To:
>> is pretty much required (yes, you can use cc: and bcc: without any
>> address on To:, but that is not something you'd usually do to send
>> patches to mailing lists), so lack of it means either asking
>> interactively or aborting.  But other things like in-reply-to are
>> optional, and tying the decision to prompt for them or not does not
>> feel OK.
>
> but trying to "fix" this breaks 10 year old tests, so it is obvious
> that everyone already expects it to work this way (probably hidden
> by the fact most people don't let git-send-email prompt for "To:")
Oh, I agree with that 100%.
> -Only necessary if --compose is also set.  If --compose
> -is not set, this will be prompted for.
> +If --compose is not set, and there is no known "To:" this will be prompted for.

The updated sentence structure, with or without the mention of "to:", reads much better than the original.

The original told them that they must give it from the command line in "--compose" mode, because they will not be given the chance to give it interactively, and the intended target audience was those who want to send a message with in-reply-to (which is natural, as this is a description for that option).

The updated message says the same thing, but is audience-neutral and tries to be more useful to folks who are not responding to any message. I.e. outside "--compose" mode, you'll be asked if you want to make it a response, unless you gave "to:".

By losing the "we won't ask so you must give it from the command line" message in the original, the resulting description has become easier to follow, I think. Those who do want to add the header, when they reach this description in the manual, already knows that there is a command line option.

To help those who do not want to add this header, it would probably be more helpful to tell what to do when prompted (like "you can give an empty answer to tell the command that you are not responding to any message").

Thanks.
Previous: Carlo Marcelo Arenas BelónNext: Drew DeVault
Message 14 of 29 in “send-email: do not prompt for In-Reply-To”
  1. send-email: do not prompt for In-Reply-ToDrew DeVault, Aug 27, 2020
  2. Junio C HamanoAug 27, 2020
  3. Junio C HamanoAug 27, 2020
  4. Drew DeVaultAug 27, 2020
  5. Junio C HamanoAug 27, 2020
  6. Drew DeVaultAug 27, 2020
  7. Carlo Marcelo Arenas BelónAug 27, 2020
  8. Drew DeVaultAug 27, 2020
  9. Carlo Marcelo Arenas BelónAug 27, 2020
  10. Junio C HamanoAug 27, 2020
  11. Drew DeVaultAug 27, 2020
  12. Carlo ArenasAug 27, 2020
  13. Carlo Marcelo Arenas BelónAug 27, 2020
  14. Junio C HamanoAug 27, 2020
  15. Drew DeVaultAug 27, 2020
  16. Drew DeVaultAug 27, 2020
  17. Junio C HamanoAug 28, 2020
  18. Drew DeVaultAug 28, 2020
  19. Raymond E. PascoAug 28, 2020
  20. Drew DeVaultAug 28, 2020
  21. Junio C HamanoAug 27, 2020
  22. Drew DeVaultAug 27, 2020
  23. Drew DeVaultAug 28, 2020
  24. Junio C HamanoAug 28, 2020
  25. Drew DeVaultAug 28, 2020
  26. Junio C HamanoAug 28, 2020
  27. Drew DeVaultAug 28, 2020
  28. Raymond E. PascoAug 28, 2020
  29. Drew DeVaultAug 27, 2020

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.