第一次给Kernel邮件列表交Patch遇到的小坑

第一次交PATCH，交成了这样：

而我交patch的方式只不过是：

git format-patch 457391b0380335d5e9a5babdec90ac53928b23b4 --cover-letter
# edit cover letter
git send-email \
        --from 'Yangyu Chen <cyy@cyyself.name>' \
        --to $to_list \
        --cc $cc_list \
        *.patch

起初以为只是个意外，直到我交了PATCH v2，它依然是这样出现在邮件列表：

于是我开始寻找原因，最后发现是我的邮件服务提供商会override邮件中的Message ID，这个ID由git send-email生成，并在后续的patch使用直接In-reply-to指明该ID，但由于这个Message ID被Override了，所以会导致In-reply-to原有的ID找不到，因此导致了这样的结果。

既然这样，我们显然有一种简单的解决方法，除了换邮箱外（对于域名邮箱当然可以换提供商），一种workaround就是我们先发送cover letter，然后查看被邮件服务商override之后的Message ID，再将后续的patch作为这个Message ID的回复即可。

后续经dram提醒，我们在使用这种方式发送邮件时需要在git send-mail加上--no-thread参数，否则就会导致除patch1外所有后续邮件加上in-reply-to第一个patch（而非cover letter），在这种情况下这是灾难，将导致邮件Thread变成这样：

-  [PATCH 0/x] cover letter
  - [PATCH 1/x] patch 1
    - [PATCH 2/x] patch 2
    - [PATCH 3/x] patch 3

最后总结出发邮件方法如下：

git send-email 0000-cover-letter.patch
# 然后等待第一封邮件到达后查看被篡改的Message-ID，作为后续的in-reply-to
git send-email --in-reply-to='<xxxx>' --no-thread 0001-xxxx.patch 0002-xxxx.patch

目前已知，针对个人的Outlook和QQ邮箱（含deprecated域名邮箱）都有此问题，而exmail.qq.com无此问题。

还要提醒大家注意的是，测试邮箱的时候需要小心git自动添加的CC，别打扰到别人了。