新しい ARM プラットフォームをサポートする Linux リポジトリがあります。これを ARM カーネル dev メーリング リストに投稿して、フィードバックを得て、できれば最終的にメインライン化したいと考えています。残念ながら、大量のコードがあり、git format-patch約 100 個のパッチ ファイルが吐き出されます。
それらを論理的な変更にグループ化するのが最善であると読みましたが、新しい ARM プラットフォームでは、各部分が次の部分と同じくらい重要です。私にできることはおそらく、基本的なプラットフォーム サポート コードをドライバー コードから分離することです。
さらに、以前のコミットには、再起動コードの修正や、パッチセットに含めたくないその他の修正など、非常に漠然としたコミット メッセージがあります。
メーリングリストを爆撃せずに私の変更を伝える最良の方法は何ですか? それを 1 つの巨大なパッチに押しつぶす必要がありますか? どういうわけか、100 個のパッチ ファイルを送信しても、良い第一印象が得られるとは思えません。
乾杯、
現在のメインライン カーネル (現時点では v3.8) に対してインタラクティブなリベースを行うことをお勧めします。これは次のようになります。
git rebase -i origin/v3.8
可能な場合は、関連するコミットを一緒につぶします。たとえば、おそらくドライバーごとに 1 つのコミットと、コア コードの論理部分ごとに 1 つのコミットを行う必要があります。それらが相互に依存していても問題ありませんが、周期的であってはなりません。開発中にすべてのバグ修正を保存する必要はありません。目標は、パッチを理解しやすく統合しやすくすることであり、歴史的に正確なストーリーを語らせることではありません。
既存のコミットを分割する必要がある場合は、 を選択editして実行できますgit add -p。これにより、差分ハンクを対話的に選択し、一度に 1 つずつコミットできます (この後、必要に応じていつでも並べ替えとスカッシュに戻ることができます)。
これが完了すると、人々が理解しやすいパッチセットが得られるはずです (そして、できれば有益なコメントが付いていることを願っています)。ドライバーを除くコア部分 (つまり、1/n、2/n、3/n...) のパッチセットを生成し、最初に提出することをお勧めします。それに対処したら、ドライバーをプッシュし始めることができます。