一 配置git和smtp
git
git config --global user.name “xxx”
git config --global user.email “xxx@xxx.com”
需要下载email相关的包 - libmailtools-perl 等
smtp
vi ~/.gitconfig //在文件末尾添加[sendemail]
[user]
name = xxx
email = xxx@xxx.com
[core]
editor = vim
[gitreview]
username = xxx
[commit]
template = /root/.gitcommit
[sendemail]
smtpencryption = ssl
smtpserver = smtp.exmail.qq.com //根据个人邮箱进行修改
smtpuser = xxx@xxx.com //根据个人邮箱进行修改
smtpserverport = 465
上述修改完成后要记得保留客户端授权密码,一般是会点击开启 POP/SMTP时生成
二 根据修改内容编写commit信息
查询修改补丁需要发送给maintainer、commiter的相关人员是谁:
1、可以查看修改相同文件之前提交信息,eg:
git log -p drivers/spi/spi-cadence-quadspi.c
2、固定格式:
spi: cadence-quadspi: setup ADDR Bits in cmd reads
xxx
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230125081023.1573712-4-d-gole@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
应该是固定格式,表示我们要修改的源文件, 后面紧接着是一条概括性的语句,概况本次提交的主要内容
接着下面用一个段落来详细描述本次提交的内容,可以介绍一下修改的内容,修改的原因等等
第三段是签名的内容,签名主要是为提交者署名,正常提交时,我们在 commit 时加入 -v
参数后会自动在commit message后面添加上自己的签名
第一条内容就是提交者的签名
第二条内容是这条提交的邮件讨论链接,记录了从代码提交到交流到最终合并的过程
第三条内容是合并你的代码的人员的签名。
其中第一条是自己添加,第二条和第三条是在合并代码时自动添加的。
三 根据修改内容生成patch
git format-patch --subject-prefix=‘PATCH’ -1
–subject-prefix 是为邮件标题添加个前缀,
*前缀* | *含义* |
---|---|
PATCH | 常规的且正式的补丁 |
RFC | 不是要正式提上去的,希望一起讨论这个补丁,用来说明方向,看看意见 |
RESEND | 邮件发过了但好几周都没人鸟,可能被遗忘了,重新发 |
patch检查:
./scripts/checkpatch.pl 0001-drivers-format-the-code.patch
需要做到0 errors和0warnings
内核代码编译,只编译有所更改的模块:
四 邮件发送patch
通过邮件方式发送patch
1)做测试,发给自己
git send-email --to xxx@xxx.com --cc xxx@xxx.com 0001-xxxx-.patch
2)测试没问题后,查找maintainer的邮件,下面两种方式都可:
./scripts/get_maintainer.pl -f drivers/vfio/vfio_iommu_type1.c
./scripts/get_maintainer.pl 0001-xxxx.patch
对于小的补丁,你也许会CC到搜集琐碎补丁的邮件列表(Trivial Patch Monkey) trivial@kernel.org,那里专门收集琐碎的补丁。下面这样的补丁会被看作“琐碎的” 补丁
文档的拼写修正。
修正会影响到 grep(1) 的拼写。
警告信息修正(频繁的打印无用的警告是不好的。)
编译错误修正(代码逻辑的确是对的,只是编译有问题。)
运行时修正(只要真的修正了错误。)
移除使用了被废弃的函数/宏的代码(例如 check_region。)
联系方式和文档修正。
用可移植的代码替换不可移植的代码(即使在体系结构相关的代码中,既然有人拷贝,只要它是琐碎的)
任何文件的作者/维护者对该文件的改动(例如 patch monkey 在重传模式下)
3)发送patch
git send-email --to alex.williamson@redhat.com \
-cc cohuck@redhat.com \
-cc kvm@vger.kernel.org \
-cc linux-kernel@vger.kernel.org
/path/to/YOURPATCH
4)后续
静静的等待维护者的邮件通知吧,一般几天之内就会回复邮件然后表示Apllied,Thanks或告知预计要合入到下一版本的如linux-5.18,有时第二天就回复一般是patch有问题。
如果patch有问题,需要回复邮件说明疑问,或直接按maintainer的要求修改补丁变成V2版本再次提交。再次提交V2版本需要注意在补丁说明中添加v1->v2的变化(patch中—分隔符之后):
...Signed-off-by: Author author@mail
V2 -> V3: Removed redundant helper function
V1 -> V2: Cleaned up coding style and addressed review comments
path/to/file | 5++±-
…
如果是回复补丁的话,可以按照如下格式发送新版patch或说明txt
git send-email \
--in-reply-to=20220615073348.6891-1-xxx@xxx.com \ (Message-ID)
--to=xxx@xxx.com \
--cc=xxx@xxx.org \
/path/to/YOUR_REPLY
其中,Message-ID可以在任一带有官方性质的邮件记录网址如(Project List - Patchwork,All of lore.kernel.org,Projects | Patchew 等等)查看,一般是“时间戳+邮件地址”的形式,最后是你的补丁或文本注释。