我正在尝试使用 Linux 股票内核（linus 树）。但是由于我的 Linux 机器的一些限制，我无法通过 git 拉树。所以我正在从 kernel.org 下载最新的 rc 候选源存档，然后创建我自己的 git 存储库，将基本源视为主源。现在我从中创建了一个分支并尝试修复一些来源。我已经能够创建一个补丁git format-patch并想提交它。再次由于没有可用的互联网连接，我必须将补丁文件传输到其他机器并发出 git send-email 命令。我的问题：
1. 我做对了吗？我的意思是补丁不是直接生成 git clone 源而是在我的本地存储库中生成的（但是是的，基本源与 linus 树相同）
2. 我看到在生成的补丁中最后一行有一些数字。
例如
--
1.7.7.3
如果我的更改得到维护者的批准，不确定它是怎么回事，它是否会影响在基础源中应用？
可以发送针对主 git 树以外的其他内容生成的补丁，只要补丁干净地应用于您希望维护者将其应用到的树。我可以看到您的工作流程有问题的一种情况是，如果您下载了最终版本（例如 3.6），然后在合并窗口期间（Linux 发布 3.6 和他发布 3.7-rc1 之间的时间）发送补丁。在合并窗口中，Linus 的树中添加了许多更改，如果其中一些更改触及您正在修补的同一个地方，那么您可能需要调整您的补丁。
无论如何，git format-patch它是创建您发送的补丁的绝佳选择，因为您将避免许多初学者遇到的补丁格式问题。此外，出于同样的原因，使用git send-email发送它是一个好主意——您避免让您的邮件客户端弄乱空格，将其转换为 HTML，或者它可能做的任何其他烦人的事情。
最后两行像
--
1.7.7.3
只显示生成补丁文件的 git 版本。当使用 、 或其他方式应用补丁时git apply，git am这两patch -p1行将被忽略并丢弃，因此它们无效。
综上所述，我建议您更新您的开发环境，以便您可以下载完整的 git 树。拥有多年的历史对于理解代码非常有用，更新到树的最新状态要快得多，而且您只需要下载增量更改。下载和修补源的ketchup工具也很有用，虽然在我看来不如直接使用 git 好。
祝你提交补丁好运！