Lines Matching +full:make +full:- +full:git +full:- +full:archive
1 .. SPDX-License-Identifier: GPL-2.0-or-later
3 .. include:: ../disclaimer-zh_CN.rst
7 :Original: Documentation/process/submitting-patches.rst
10 - 钟宇 TripleX Chung <xxx.phy@gmail.com>
11 - 时奎亮 Alex Shi <alexs@kernel.org>
12 - 吴想成 Wu XiangCheng <bobwxc@email.cn>
15 - 李阳 Li Yang <leoyang.li@nxp.com>
16 - 王聪 Wang Cong <xiyou.wangcong@gmail.com>
27 参见： Documentation/translations/zh_CN/process/development-process.rst 。
28 Documentation/translations/zh_CN/process/submit-checklist.rst 给出了一系列
30 Documentation/devicetree/bindings/submitting-patches.rst 。
32 本文档假设您正在使用 ``git`` 准备你的补丁。如果您不熟悉 ``git`` ，最好学习
36 Documentation/process/maintainer-handbooks.rst 。
39 --------------
41 如果您手头没有当前内核源代码的存储库，请使用 ``git`` 获取一份。您需要先获取
44 git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
53 ------------
74 码管理系统 ``git`` 中，那么维护人员将非常感谢您。
85 用祈使句描述你的变更，例如“make xyzzy do frotz”而不是“[This patch]make
89 如果您想要引用一个特定的提交，不要只引用提交的SHA-1 ID。还请包括提交的一行
97 您还应该确保至少使用前12位SHA-1 ID。内核存储库包含 *许多* 对象，使较短的ID
106 ``Message-ID`` 头（去掉尖括号）可以创建链接URL。例如::
115 如果补丁修复了特定提交中的错误，例如使用 ``git bisct`` 发现了一个问题，请使用
116 带有前12个字符SHA-1 ID的“Fixes:”标签和单行摘要。为了简化解析脚本，不要将该
119 …Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually fre…
121 下列 ``git config`` 设置可以让 ``git log``, ``git show`` 增加上述风格的显示格式::
130 $ git log -1 --pretty=fixes 54a4f0239f2e
131 …Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually fre…
136 ------------
154 都能正常构建和运行。使用 ``git bisect`` 来追踪问题的开发者可能会在任何地方分
161 ----------------
164 Documentation/translations/zh_CN/process/coding-style.rst
178 - ERROR：很可能出错的事情
179 - WARNING：需要仔细审阅的事项
180 - CHECK：需要思考的事情
185 --------------
190 的维护人员，那么Andrew Morton（akpm@linux-foundation.org）将充当最后的维护
193 您通常还应该选择至少一个邮件列表来接收补丁集的副本。linux-kernel@vger.kernel.org
202 torvalds@linux-foundation.org 。他收到的邮件很多，所以一般来说最好 **别**
208 参见 Documentation/translations/zh_CN/process/security-bugs.rst 。
216 Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
220 更改抄送到 linux-api@vger.kernel.org 。
224 ------------------------------------------------------
231 是使用 ``git send-email`` 。https://git-send-email.io 有 ``git send-email``
234 如果你选择不用 ``git send-email`` ：
238 如果你使用剪切-粘贴你的补丁，小心你的编辑器的自动换行功能破坏你的补丁
247 请参阅 Documentation/translations/zh_CN/process/email-clients.rst
251 ------------
266 ----------------
283 ----------------
285 由于到Linus和linux-kernel的电子邮件流量很高，通常会在主题行前面加上[PATCH]
288 ``git send-email`` 会自动为你加上。
291 ------------------------------
294 们在通过邮件发送的补丁上引入了“签署（sign-off）”流程。
316 一起提交的个人记录，包括sign-off）被永久维护并且可以和这个项目
321 Signed-off-by: Random J Developer <random@developer.example.org>
323 使用你的真名（抱歉，不能使用假名或者匿名。）如果使用 ``git commit -s`` 的话
324 将会自动完成。撤销也应当包含“Signed-off-by”， ``git revert -s`` 会帮你搞定。
329 作者签署之后的任何其他签署（Signed-off-by:'s）均来自处理和传递补丁的人员，但
333 何时使用Acked-by:，Cc:，和Co-developed-by:
334 ------------------------------------------
336 Signed-off-by: 标签表示签名者参与了补丁的开发，或者他/她在补丁的传递路径中。
339 那么他们可以要求在补丁的变更日志中添加一个Acked-by:。
341 Acked-by: 通常由受影响代码的维护者使用，当该维护者既没有贡献也没有转发补丁时。
343 Acked-by: 不像签署那样正式。这是一个记录，确认人至少审阅了补丁，并表示接受。
344 因此，补丁合并有时会手动将Acker的“Yep，looks good to me”转换为 Acked-By:（但
347 Acked-by：不一定表示对整个补丁的确认。例如，如果一个补丁影响多个子系统，并且
348 有一个来自某个子系统维护者的Acked-By:，那么这通常表示只确认影响维护者代码的部
355 Co-developed-by: 声明补丁是由多个开发人员共同创建的；当几个人在一个补丁上工
356 作时，它用于给出共同作者（除了From:所给出的作者之外）。因为Co-developed-by:
357 表示作者身份，所以每个Co-developed-by:必须紧跟在相关合作作者的签署之后。标准
358 签署程序要求Signed-off-by:标签的顺序应尽可能反映补丁的时间历史，无论作者是通
359 过From:还是Co-developed-by:表明。值得注意的是，最后一个Signed-off-by:必须是
368 Co-developed-by: First Co-Author <first@coauthor.example.org>
369 Signed-off-by: First Co-Author <first@coauthor.example.org>
370 Co-developed-by: Second Co-Author <second@coauthor.example.org>
371 Signed-off-by: Second Co-Author <second@coauthor.example.org>
372 Signed-off-by: From Author <from@author.example.org>
380 Co-developed-by: Random Co-Author <random@coauthor.example.org>
381 Signed-off-by: Random Co-Author <random@coauthor.example.org>
382 Signed-off-by: From Author <from@author.example.org>
383 Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
384 Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
387 使用Reported-by:、Tested-by:、Reviewed-by:、Suggested-by:和Fixes:
388 -----------------------------------------------------------------
390 Reported-by: 给那些发现错误并报告错误的人致谢，它希望激励他们在将来再次帮助
391 我们。请注意，如果bug是以私有方式报告的，那么在使用Reported-by标签之前，请
394 Tested-by: 标签表示补丁已由指定的人（在某些环境中）成功测试。这个标签通知
397 Reviewed-by：根据审阅者的监督声明，表明该补丁已被审阅并被认为是可接受的：
403 通过提供我的Reviewed-by:标签，我声明：
418 Reviewed-by是一种观点声明，即补丁是对内核的适当修改，没有任何遗留的严重技术
419 问题。任何感兴趣的审阅者（完成工作的人）都可以为一个补丁提供一个Reviewed-by
421 当Reviewed-by:标签由已知了解主题区域并执行彻底检查的审阅者提供时，通常会增加
424 一旦从测试人员或审阅者的“Tested-by”和“Reviewed-by”标签出现在邮件列表中，
427 （在 ``---`` 分隔符之后）应该提到删除某人的测试者或审阅者标签。
429 Suggested-by: 表示补丁的想法是由指定的人提出的，并确保将此想法归功于指定的
442 Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
447 ------------
449 本节描述如何格式化补丁本身。请注意，如果您的补丁存储在 ``Git`` 存储库中，则
450 可以使用 ``git format-patch`` 进行正确的补丁格式化。但是，这些工具无法创建
459 - 一个 ``from`` 行指出补丁作者。后跟空行（仅当发送补丁的人不是作者时才需要）。
461 - 说明文字，每行最长75列，这将被复制到永久变更日志来描述这个补丁。
463 - 一个空行
465 - 上述的 ``Signed-off-by:`` 行，也将出现在更改日志中。
467 - 只包含 ``---`` 的标记线。
469 - 任何其他不适合放在变更日志的注释。
471 - 实际补丁（ ``diff`` 输出）。
482 记住邮件的“一句话概述”会成为该补丁的全局唯一标识。它会进入 ``git``
485 章。当人们在两三个月后使用诸如 ``gitk`` 或 ``git log --oneline`` 之类
488 出于这些原因，概述必须不超过70-75个字符，并且必须描述补丁的更改以及为
519 ``---`` 标记行对于补丁处理工具要找到哪里是改动日志信息的结束，是不可缺少
522 对于 ``---`` 标记之后的额外注解，一个好的用途就是用来写 ``diffstat`` ，用来显
525 使用 ``diffstat`` 的选项 ``-p 1 -w 70`` 这样文件名就会从内核源代码树的目录开始
527 （ ``git`` 默认会生成合适的diffstat。）
532 请将此信息放在将变更日志与补丁的其余部分分隔开的 ``---`` 行 **之后** 。版本
539 Signed-off-by: Author <author@mail>
540 ---
541 V2 -> V3: Removed redundant helper function
542 V1 -> V2: Cleaned up coding style and addressed review comments
544 path/to/file | 5+++--
570 明确回复邮件头（In-Reply-To）
571 -----------------------------
573 手动添加回复补丁的的邮件头（In-Reply_To:）是有用的（例如，使用 ``git send-email`` ），
581 --------------
587 如果您使用 ``git format-patch`` 生成补丁，则可以通过 ``--base`` 标志在提交中
590 $ git checkout -t -b my-topical-branch master
591 Branch 'my-topical-branch' set up to track local branch 'master'.
592 Switched to a new branch 'my-topical-branch'
596 $ git format-patch --base=auto --cover-letter -o outgoing/ master
597 outgoing/0000-cover-letter.patch
598 outgoing/0001-First-Commit.patch
601 当你编辑 ``outgoing/0000-cover-letter.patch`` 时，您会注意到在它的最底部有一
602 行 ``base-commit:`` 尾注，它为审阅者和CI工具提供了足够的信息以正确执行
603 ``git am`` 而不必担心冲突::
605 $ git checkout -b patch-review [base-commit-id]
606 Switched to a new branch 'patch-review'
607 $ git am patches.mbox
611 有关此选项的更多信息，请参阅 ``man git-format-patch`` 。
615 ``--base`` 功能是在2.9.0版git中引入的。
617 如果您不使用git格式化补丁，仍然可以包含相同的 ``base-commit`` 尾注，以指示您
619 该放在 ``---`` 行的下面或所有其他内容之后，即只在你的电子邮件签名之前。
622 ----
629 --------
635 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
637 Greg Kroah-Hartman，“如何惹恼内核子系统维护人员”
640 <http://www.kroah.com/log/linux/maintainer-02.html>
642 <http://www.kroah.com/log/linux/maintainer-03.html>
644 <http://www.kroah.com/log/linux/maintainer-04.html>
646 <http://www.kroah.com/log/linux/maintainer-05.html>
648 <http://www.kroah.com/log/linux/maintainer-06.html>
650 内核 Documentation/translations/zh_CN/process/coding-style.rst
658 http://halobates.de/on-submitting-patches.pdf