git send-email 发送邮件失败

git send-email fail to send message

我正在尝试发送 git 补丁以供上游社区审核;但是接收者没有收到消息;

我已尝试将“--to”更改为我的私人电子邮件 ID 之一,但我的私人邮箱也收不到;

命令:

git send-email --no-chain-reply-to --from "Ganapathi Bhat <xxx@gmail.com>" --to linux-wireless@vger.kernel.org my_patch.patch

输出:

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

命令:

git config -l

输出:

user.email=xxx@gmail.com
user.name=Ganapathi Bhat
sendemail.smtpencryption=tls
sendemail.smtpserver=smtp.gmail.com
sendemail.smtpuser=xxx@gmail.com
sendemail.smtpserverport=587

补丁应该被提交给社区进行审查,它应该出现在下面的列表中: https://patchwork.kernel.org/project/linux-wireless/list/

考虑 git send-email man page,测试添加等号 ('=') 是否会改变任何内容:

git send-email --no-chain-reply-to --from="Ganapathi Bhat" --to=linux-wireless@vger.kernel.org my_patch.patch
                                        ^^^                   ^^^

下一步是检查您的 sendemail configgit config -l
参见 Git Tips
例如,对于 GMail:

git send-email现在支持TSL/SSL,所以使用gmail就像设置以下配置变量一样简单:

[sendemail]
    smtpencryption = tls
    smtpserver = smtp.gmail.com
    smtpuser = yourname@gmail.com
    smtpserverport = 587

OP Ganapathi Bhat confirm a configuration issue :

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


说到 sendmail 配置,一定要使用 sendemail!

Git 2.29(2020 年第 4 季度)将在定义“sendmail.*”配置变量时停止,这可能是定义“sendemail.*”变量的错误尝试。

commit dd84e52 (23 Jul 2020) by Drew DeVault (ddevault)
(由 Junio C Hamano -- gitster -- in commit a00bda2 合并,2020 年 8 月 17 日)

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 现在包含在其 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.


使用 Git 2.33(2021 年第 3 季度),“git send-email"(man) 得到了一些优化,其中一些与上述提交相关。

参见 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)
(由 Junio C Hamano -- gitster -- in commit 8de2e2e 合并,2021 年 7 月 22 日)

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.


注意:Git 2.33 上面的功能损坏了 gitk,已用 Git 2.34(2021 年第 4 季度)修复:

参见 commit b996f84 (06 Sep 2021) by Ævar Arnfjörð Bjarmason (avar)
(由 Junio C Hamano -- gitster -- in commit 10de757 合并,2021 年 9 月 15 日)

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.