我正在尝试使用Linux stock kernel（linus tree）。但由于我的Linux机箱有一些限制，我不能通过git拉树。所以我从kernel.org下载最新的rc候选源存档，然后创建我自己的git存储库，将基源作为master。现在我从中创建了一个分支并尝试修复一些来源。我已经能够通过git format-patch创建补丁并想提交它。再次由于没有互联网连接可用性，我必须将补丁文件传输到其他机器并发出git send-email命令。我的问题：
我做得对吗？我的意思是补丁生成不是直接git克隆源，而是在我的本地存储库（但是基础源与linus树相同）
我已经看到在生成的补丁中，最后一行有一些数字。
例如
-
1.7.7.3
如果我的更改得到维护者的批准，不确定它的全部内容并且在应用基础源时是否有影响？
答案 0 :(得分：2)
只要补丁适用于您希望维护者将其应用到的树，就可以发送针对除主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那么好。
祝你好运提交你的补丁！