git send-email fail to send message

Question

I am trying to send a git patch for a upstream community review; But the receiver does not receive the message;

I have tried changing '--to' to one of my private email-id, but even this is not being received at my private mailbox;

command:

git send-email --no-chain-reply-to --from "Ganapathi Bhat <[email protected]>" --to [email protected] my_patch.patch

output:

Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES: server=smtp.gmail.com encryption=tls hello=yyy.yyy.com port=587 at /usr/lib/git-core/git-send-email line 1506

command:

git config -l

output:

[email protected]
user.name=Ganapathi Bhat
sendemail.smtpencryption=tls
sendemail.smtpserver=smtp.gmail.com
[email protected]
sendemail.smtpserverport=587

The patch should get delivered to the community for review process and it should appear in below list: https://patchwork.kernel.org/project/linux-wireless/list/

Answer 1

Considering git send-email man page, test if adding an equal ('=') changes anything:

git send-email --no-chain-reply-to --from="Ganapathi Bhat" [email protected] my_patch.patch
                                        ^^^                   ^^^

The next step is to check your sendemail config: git config -l
See Git Tips.
For example, with GMail:

git send-email now supports TSL/SSL, so using gmail is as simple as setting the following configuration variables:

[sendemail]
    smtpencryption = tls
    smtpserver = smtp.gmail.com
    smtpuser = [email protected]
    smtpserverport = 587

The OP Ganapathi Bhat confirm a configuration issue in the comments:

git send-email fail to send message

I was using wrong "smtpserver";
I contacted the IT person, got the correct "smtpserver" to be used, which fixed the issue.

---

Speaking of sendmail config, make sure to use sendemail!

Git 2.29 (Q4 2020) will stop when "sendmail.*" configuration variables are defined, which could be a mistaken attempt to define "sendemail.*" variables.

See commit dd84e52 (23 Jul 2020) by Drew DeVault (ddevault).
^{(Merged by Junio C Hamano -- gitster -- in commit a00bda2, 17 Aug 2020)}

git-send-email: die if sendmail.* config is set

^{Signed-off-by: Drew DeVault}

I've seen several people mis-configure git send-email^(man) on their first attempt because they set the sendmail.* config options - not sendemail.*.
This patch detects this mistake and bails out with a friendly warning.

git config now includes in its man page:

sendemail.forbidSendmailVariables

To avoid common misconfiguration mistakes, git send-email will abort with a warning if any configuration options for "sendmail" exist. Set this variable to bypass the check.

---

With Git 2.33 (Q3 2021), "git send-email"^(man) gets some optimization, some related to commits mentioned above.

See commit 17530b2, commit c95e3a3, commit 5a544a4, commit f4dc943, commit 447ed29, commit 4adbf38, commit fef381e, commit 9264d29, commit 2b110e9, commit 119974e, commit 671818a, commit 879be43, commit ecc4ee9 (28 May 2021) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 8de2e2e, 22 Jul 2021)}

send-email: lazily load config for a big speedup

^{Signed-off-by: Ævar Arnfjörð Bjarmason}

Reduce the time it takes git-send-email^(man) to get to even the most trivial of tasks (such as serving up its "-h" output) by first listing config keys that exist, and only then only call e.g. "git config --bool"^(man) on them if they do.

Over a lot of runs this speeds the time to "-h" up for me from ~250ms to ~150ms, and the runtime of t9001-send-email.sh goes from ~25s to ~20s.

This introduces a race condition where we'll do the "wrong" thing if a config key were to be inserted between us discovering the list and calling read_config(), i.e.
we won't know about the racily added key.
In theory this is a change in behavior, in practice it doesn't matter.

The config_regexp() function being changed here was added in dd84e52 ("git-send-email: die if sendmail.* config is set", 2020-07-23, Git v2.29.0-rc0 -- merge listed in batch #8) for use by git-send-email.
So we can change its odd return value in the case where no values are found by git config".
The difference in the *.pm code would matter if it was invoked in scalar context, but now it no longer is.

---

Note: Git 2.33 feature above broke gitk, which has been fixed with Git 2.34 (Q4 2021):

See commit b996f84 (06 Sep 2021) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 10de757, 15 Sep 2021)}

send-email: fix a "first config key wins" regression in v2.33.0

^{Reported-by: Eli Schwartz
Tested-by: Eli Schwartz
Signed-off-by: Ævar Arnfjörð Bjarmason}

Fix a regression in my c95e3a3 ("send-email: move trivial config handling to Perl", 2021-05-28, Git v2.33.0-rc0 -- merge listed in batch #6) where we'd pick the first config key out of multiple defined ones, instead of using the normal "last key wins" semantics of "git config --get"^(man)".

This broke e.g. cases where a .git/config would have a different sendemail.smtpServer than ~/.gitconfig.
We'd pick the ~/.gitconfig over .git/config, instead of preferring the repository-local version.
The same would go for /etc/gitconfig etc.

I.e.
having any of these set in say ~/.gitconfig and in-repo .git/config regressed in v2.33.0 to prefer the --global one over the --local.