1

Linuxストックカーネル（linusツリー）で作業しようとしています。しかし、私の Linux ボックスの制限により、git を介してツリーをプルすることはできません。そのため、kernel.org から最新の rc 候補ソース アーカイブをダウンロードし、ベース ソースをマスターとして扱う独自の git リポジトリを作成しています。今、そこからブランチを作成し、いくつかのソースを修正しようとしています。パッチを作成できたgit format-patchので、提出したいと思いました。ここでもインターネット接続が利用できないため、パッチ ファイルを他のマシンに転送し、git send-email コマンドを発行する必要があります。私の質問:
1. 私のやり方は正しいですか? つまり、パッチは git clone ソースを直接生成するのではなく、私のローカル リポジトリに生成します (ただし、ベース ソースは linus ツリーと同じです)
2. 生成されたパッチの最後の行にいくつかの数字があることがわかりました。

例えば

--
1.7.7.3
私の変更がメンテナーによって承認された場合、それが何であるか、またベースソースに適用する際に影響があるのか​​わからない?

4

1 に答える 1

2

メインの git ツリー以外に対して生成されたパッチを送信しても問題ありませんが、メンテナーがパッチを適用すると予想されるツリーに対してパッチが完全に適用される限りは問題ありません。ワークフローに問題があると思われる 1 つのケースは、最終リリース (たとえば 3.6) をダウンロードし、マージ ウィンドウ (Linux が 3.6 をリリースしてから 3.7-rc1 をリリースするまでの時間) 中にパッチを送信した場合です。マージ ウィンドウでは、Linus のツリーに多くの変更が追加されます。パッチを適用している場所と同じ場所に変更が加えられている場合は、パッチを調整する必要があります。

いずれにせよ、git format-patch初心者が遭遇する多くのパッチのフォーマットの問題を回避できるため、送信するパッチを作成するには を選択することをお勧めします。また、 を使用git send-emailして送信することも同じ理由で優れたアイデアです。メール クライアントが空白を台無しにしたり、HTML に変換したり、その他の煩わしい作業を回避したりできます。

のような最後の2行

--
1.7.7.3

パッチ ファイルを生成した git バージョンを表示するだけです。、などでパッチを適用するとgit apply、これらの 2 行は無視されて削除されるため、効果はありません。git ampatch -p1

とはいえ、完全な git ツリーをダウンロードできるように、開発環境の更新に取り組むことをお勧めします。長年の歴史を持つことは、コードを理解するのに非常に役立ち、ツリーの最新状態への更新ははるかに高速で、増分変更をダウンロードするだけで済みます。ソースをダウンロードしてパッチを適用するためのketchupツールも便利ですが、私の意見では、git を直接使用するほどではありません。

頑張ってパッチを提出してください!

于 2012-10-10T14:13:03.840 に答える