3

次のシナリオを検討してください。

$ git branch –a 
* dev
  master

$ git branch --contains 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6
 dev

$ git branch --contains f7dfb3689edcaf5f819fa5e691ce13abf858bca8
   dev
   master

$ git cherry master dev
+ 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6
+ a4e66dbde954f73185d61bfb78b40ac5e61fe56c
+ 6fcffbd9b57e8a74726ea2cd3713f14baaaa06f5
+ 5031ad3cdf2e81c880e9cbf049abed6f1edde3bc
+ dcca33c373df6953ff164e8d70531abd71841278

しかし、ひねりを加えたのは、コミットf7dfb3689edcaf5f819fa5e691ce13abf858bca8は実際には から選択されたもの53fdfaf89fca499c36c71d29f25eb1a13b32d4d6であり、両方がまったく同じであるということです (何らかの理由で、コミット ID が異なる 2 つのまったく同じコミットが必要だったため、ご容赦ください) コミット メッセージとコミット ID 以外に、 2 つのコミットに違いはありません。

git cherryドキュメント に従って、コミットは git patch-id プログラムから取得したパッチ ID と比較されます。

だから私は実際に先に進みgit patch-id、以下のようにプログラムを実行しました

$ git show 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 | git patch-id
bd6c061bd6c380d53832510cbaf68bebb4fb182d 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6

$ git show f7dfb3689edcaf5f819fa5e691ce13abf858bca8 | git patch-id
bd6c061bd6c380d53832510cbaf68bebb4fb182d f7dfb3689edcaf5f819fa5e691ce13abf858bca8

上記の結果は、git patch-id実際には 2 つのコミットが同じであると認識していることを示していますが、それでもgit cherryコマンドはそれを実行できません。

これが起こる唯一の理由は、git cherry以外の要因を考慮した場合git patch-idです。

ヘッド (つまり、私の場合は dev ブランチ) で行われたコミットの数を考慮していますか? dev ブランチには 2 つのバージョンのコミットがあり、master には 1 つしかないためです。

4

1 に答える 1

1

上記の出力から、cherry-picked リビジョンを dev にもマージしました (ある時点で master をマージすることにより)。Git は一連のリビジョンを調べて、完全に一致するものを見つけて、検査対象の一連のリビジョンから削除し、パッチ ID を生成しません。良いニュースは、git mergedev の元の変更が既に master にあることを引き続き認識し、その変更を再適用しようとしないことです。

チェリーピッキングを含むほとんどのワークフローでは、チェリーピッキングを含むブランチをブランチにマージすることは決してないと思います。通常は、修正を master にコミットしてから、安定したブランチにチェリー ピックします。または、あなたの場合、バグ修正を master にコミットしてから、master を dev にマージします。

コード ビハインドgit cherry hereを確認できます。ここで、パッチ ID の生成に注意してください。特に、 719 行目のコメントに注意してください。master が dev にマージされているため、dev にないリビジョンよりも master のリビジョンを要求します。したがって、パッチ ID は生成されません。その結果、チェリー ピック以外の元のリビジョンが master に引き継がれていないようです。

この動作はバグだと主張できます。しかし、それを修正すると、パフォーマンスが大幅に低下する可能性があると思います。

于 2012-12-09T11:14:41.323 に答える