英语

• 中文 (简体)

修改补丁

如果您是子系统或分支维护者，有时您需要对收到的补丁进行微调以进行合并，因为您的代码树和提交者的代码不完全相同。如果您严格遵守开发者原创证书的规则 (c)，您应该要求提交者重新生成差异，但这完全是浪费时间和精力，适得其反。规则 (b) 允许您调整代码，但改变一个提交者的代码并让他为您的错误背书是非常不礼貌的。为了解决这个问题，建议您在最后一个 Signed-off-by 头部和您的头部之间添加一行，说明您所做更改的性质。虽然这并非强制性，但似乎在描述前加上您的邮件和/或姓名，并用方括号括起来，足以明显地表明您应对最后时刻的更改负责。示例

Signed-off-by: Random J Developer <random@developer.example.org>
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>

如果您维护一个稳定分支，并且同时希望认可作者、跟踪更改、合并修复并保护提交者免受投诉，这种做法特别有用。请注意，在任何情况下，您都不能更改作者的身份（From 头部），因为这是出现在变更日志中的信息。

致回溯移植者的特别提示：在提交消息的顶部（主题行之后）插入补丁来源的指示，以方便跟踪，这似乎是一种常见且有用的做法。例如，这是我们在 3.x 稳定版中看到的内容

Date:   Tue Oct 7 07:26:38 2014 -0400

  libata: Un-break ATA blacklist

  commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.

以下是补丁回溯移植到旧内核后可能出现的内容

Date:   Tue May 13 22:12:27 2008 +0200

    wireless, airo: waitbusy() won't delay

    [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]

无论格式如何，这些信息都为跟踪您的代码树的人以及尝试解决您代码树中错误的人提供了宝贵的帮助。