2

特定の Linux バージョン、たとえば 2.6.25.4 に対して完全に機能する一連の変更があります。

私は git ツリーを持っていて、タグ v2.6.25.4 からトラッキング ブランチ バニラ-2.6.25.4 を作成しました。これから my-changes-2.6.25.4 という名前のブランチを作成し、すべての作業を行いました。

ここで、任意の新しいバージョンの Linux の上に自分の作業をリベースしたいと思います。2.6.28.9 と言います。これを達成するための最適な git ワークフローは何ですか?

2.6.28.9 から新しいブランチを作成する方法は知っていますが、「git merge my-changes-2.6.25.4」のようなことをすると、興味のない他のものからあらゆる種類の競合が発生します。これはとにかく壊れているようです。

作業中の my-changes-2.6.25.4 から新しいブランチを作成し、git rebase 2.6.28.9 を実行しようとしましたが、これにより 2.6.25.4 からの変更が取得され、2.6.28.9 の上に適用されると想定されていましたが、これにより大量の結果が得られました。私が変更したものに関係のない競合の。

これを行う適切な方法が何であるかわかりません。私は安定した Linux ツリーhttp://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.gitを使用していますが、いくつかの問題はその事実に起因する可能性があると思いますバージョン管理されたタグ v2.6.xy がすべて同じ系統からのものではないことに注意してください。

これを適切に行う方法を知っている人はいますか？Linux がインターフェイスを変更してコードを壊した次の場所を見つけるために、バイナリ検索を介して可能な限り自動的に前進する方法を考案したことに対する追加の功績ですが、実際に何をしようとしているのかがわかれば、それを自分で自動化できると思います。 .

4

1 に答える 1

2

2 番目のアプローチは正しいように聞こえますが、どのようにリベースを呼び出しましたか? ベースリビジョンを変更することを伝える必要があります。次のようなものが必要だと思います

# on changes-2.6.25.4
# make new branch
git checkout -b changes-2.6.28.9
# double-check local changes to transport
git log --pretty=oneline v2.6.25.4..
# transport changes to be against new base
git rebase --onto v2.6.28.9 v2.6.25.4
# should now have the same changes
git log --pretty=oneline v2.6.28.9..

リベースの途中でダンプされないようにするもう 1 つの方法は、ローカルの変更のリストを取得し、「git cherry-pick」コマンドを使用して v2.6.28.9 に基づく新しいブランチに手動で追加することです。実際、これはリベースと実質的に同じですが、ある意味では、自分がしていることをより細かく制御できます。

これが問題である理由についてのあなたの推論は正しいと思います: v2.6.28.9 は v2.6.25.4 の子孫ではないため、デフォルトでリベースは v2.6.26..v2.6.25 のすべての変更を含めようとします。 .4 だけでなく、「git rebase v2.6.28.9」を実行した場合。1引数のリベースは、ローカルの変更を「git log $1..HEAD」として取得し、それらを「$1」の上に適用しようとします-したがって、リベースする引数がブランチである場合にのみこれが意味をなすことがわかります更新されました。以前と同じタグをリベースしても、何も起こりません。別のタグからリベースすると、他の人の変更が自分の変更に混ざってしまいます。あるタグを別のタグにリベースする必要があります。

于 2009-05-27T09:00:48.790 に答える