我有一个Linux repo，支持一个新的ARM平台，我想发布到ARM内核开发邮件列表上以获得一些反馈，并希望最终得到主流。不幸的是，有很多代码和git format-patch吐出大约100个补丁文件。
我认为最好将它们组合成逻辑更改但是对于新的ARM平台，每个部分都与下一个部分一样重要。我能做的最多可能是从驱动程序代码中单独的基本平台支持代码。
此外，我之前的提交有非常模糊的提交消息，例如固定重启代码或 misc fixes ，我宁愿不将其包含在补丁集中。
在不轰炸邮件列表的情况下，最好的方法是获取更改？我应该将它压成一个巨大的补丁吗？不知何故，我认为发送100个补丁文件也不会给人留下良好的第一印象。
干杯，
答案 0 :(得分：2)
我建议你对当前的主线内核（目前是v3.8）进行交互式rebase。这看起来如下所示：
git rebase -i origin/v3.8
尽可能将相关提交压缩在一起，例如，您应该为每个驱动程序提交一个提交，并为核心代码的每个逻辑部分提交一个提交，如果它们彼此依赖，则可以，但它不应该是循环的。您不需要在开发期间保留所有错误修复，目标是使补丁易于理解和集成，而不是让它们讲述历史上准确的故事。
如果您需要拆分现有提交，可以选择edit，然后执行git add -p，这样您就可以交互选择差异并一次提交一个（之后您可以随时回去重新排序并在必要时挤压。）
一旦你完成了这个，你应该有一个补丁集，让人们更容易理解（希望有用的评论）。我建议你为核心部分生成一个补丁集（即1 / n，2 / n，3 / n ......），不包括驱动程序，并先提交。一旦处理好了，就可以开始推动驱动程序了。