mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: "Strawbridge, Michael" <>
Cc: "" <>,
	"Tuikov, Luben" <>
Subject: Re: [PATCH v5 2/2] send-email: expose header information to git-send-email's sendemail-validate hook
Date: Fri, 13 Jan 2023 17:17:29 -0800	[thread overview]
Message-ID: <xmqqmt6loqxi.fsf@gitster.g> (raw)
In-Reply-To: <> (Michael Strawbridge's message of "Tue, 10 Jan 2023 21:16:28 +0000")

"Strawbridge, Michael" <> writes:

> +It takes these command line arguments:
> +1. the name of the file that holds the e-mail to be sent.
> +2. the name of the file that holds the SMTP headers to be used.
> +
> +The hook doesn't need to support multiple header names (for example only Cc
> +is passed).

I think you meant, by "multiple header names", "header names spelled
in different cases".

That may be a correct statement, but is more or less a useless one
that does not help hook writers.  Different people spell these
headers in different capitalization (for example, your message came
with "CC:" to various people, not "Cc:"), so the hook MUST know
which case the feature adds to its input, if it chooses not to
support different cases like "Cc:", "cc:", and "CC:".  IOW, "only Cc
is passed" is not something they need to hear as a mear example.
They need to be told what headers are given to them and in what
capitalization for all headers in the input to them.

> However, it does need to understand that lines beginning with
> +whitespace belong to the previous header.  The header information follows
> +the same format as the confirmation given at the end of send-email.

I suspect that many people (including me) disable the confirmation
and to them, the above description would not help.

In general, documentation should not depend on the reader having an
access to an environment where they can readily run commands and see
their output.


  reply	other threads:[~2023-01-14  1:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 21:16 [PATCH v5 0/2] send-email: expose header information to git-send-email's sendemail-validate hook Strawbridge, Michael
2023-01-10 21:16 ` [PATCH v5 1/2] send-email: refactor header generation functions Strawbridge, Michael
2023-01-17 13:20   ` Ævar Arnfjörð Bjarmason
2023-01-17 15:13     ` Junio C Hamano
2023-01-17 21:36     ` Strawbridge, Michael
2023-01-10 21:16 ` [PATCH v5 2/2] send-email: expose header information to git-send-email's sendemail-validate hook Strawbridge, Michael
2023-01-14  1:17   ` Junio C Hamano [this message]
2023-01-14 16:03   ` Junio C Hamano
2023-01-14 16:06     ` Junio C Hamano
2023-01-15  3:34       ` Junio C Hamano
2023-01-17  4:09         ` Luben Tuikov
2023-01-17  4:29           ` Junio C Hamano
2023-01-17  4:56             ` Luben Tuikov
2023-01-17 13:23   ` Ævar Arnfjörð Bjarmason
2023-01-17 21:58     ` Strawbridge, Michael
2023-01-17  1:49 ` [PATCH v5 0/2] " Strawbridge, Michael
  -- strict thread matches above, loose matches on Subject: below --
2023-01-17  1:37 Strawbridge, Michael
2023-01-17  1:37 ` [PATCH v5 2/2] " Strawbridge, Michael

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqmt6loqxi.fsf@gitster.g \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).