web-dev-qa-db-ja.com

チェリーピッキングマージコミット時のメインラインの親番号

これが私のgit履歴であるとします

 Z 
 /
A-C-D 
 \/
 B

私のHEADは現在Zにあります。BとCをチェリーピックします。私の理解が正しければ、すべきです。この：

git cherry-pick B
git cherry-pick C -m 1
git commit --allow-empty

私の場合、Cは何もしません（後で空のコミットが必要になるので、他の理由でコミットが必要になりました）が、うまくいきましたが、-mの後のパラメーターはどうなるのでしょうか。ここに私が読んだものがあります ドキュメント ：

-m親番号

-メインラインの親番号

通常、マージのどちら側をメインラインと見なすべきかわからないため、マージをチェリーピックすることはできません。このオプションは、メインラインの親番号（1から始まる）を指定し、チェリーピックが指定された親に関連する変更を再生できるようにします。

私の場合、Cには2つの親がありますが、どちらが1と2であるかを知るにはどうすればよいですか。

gitcherry-pickgit-cherry-pick
18
rink.attendant.6

この答え に基づく私の理解は、親1がマージされるブランチであり、親2がマージされるブランチであるということです。したがって、あなたの場合、親1はAであり、親2はBです。チェリーピックは実際に2つのコミット間の差分を適用しているので、-m 1を使用してBからの変更のみを適用します（AとCの差分にはB）から変更されます。あなたの場合、AとCの間にコミットがないため、おそらく問題ではありません。

はい、-m 1が望みです。AとCの間に余分なコミットがあったとしても、それは事実です。

新しい履歴を元の履歴のように見せたい場合、別の方法があります：

git cherry-pick B
git checkout Z
git merge --no-ff --no-commit B
git commit --author="Some Dev <[email protected]>" --date="<commit C author date>"

（必要に応じて、チェリーピッキングの前にBの新しいブランチを作成できます。）

これにより著者情報が保持され、次のような履歴が表示されます。

    B'
   /  \
  Z -- C'
 /
A -- C -- D
 \  /      
  B
23
Scott Weldon

Scott Weldon's answer を支持しましたが、これは正しいですが、ただASCII親の番号付けを含むアート。この：

       B
      / \
...--A   D--...
      \ /
       C

ノードDがマージコミットであることはわかりますが、BまたはCがDの最初の親であるかどうかはわかりません。 2つのうちの1つは必然的に最初の親であり、もう1つは2番目の親です。そのため、知る必要がある場合は、図面にラベルを付ける必要があります。そのような試みの1つを次に示します。

         B
       /   \²
...--A       D--...
       \   /¹
         C

なんらかの理由で、1 グラフを「逆さまに」描画しました。コミットCは実際にはDの最初の親であり、コミットBは2番目の親です。

低レベル（「配管」）コマンドを使用して、任意のマージを作成することができます。特に、git commit-treeは、与えたい順番で、与えたい数の-p引数を取り、与えられたコミットを親として新しいコミットを行います。 -pを1つ与えると、1つの親と通常のコミットを行います。 -p引数を指定せずに、ルートコミットを行います。 155個の-p引数を指定し（もちろん、すべて有効なコミットIDに解決する必要があります）、1つの巨大なタコマージコミットを作成します。

ただし、git mergeコマンドは常に、最初の親が現在のHEADである新しいブランチを作成します（ブランチの場合は現在のブランチです）。標準の2つの親のマージの場合、2番目の親は.git/MERGE_HEADから取得され、git mergeは別のコミットIDを書き込みます。マージが競合する場合、または最終的なマージコミットが--no-commitで遅延する場合、このMERGE_HEADファイルは実際にはonlyコミットIDが利用できる場所。

（git mergeが-s octopusストラテジーを使用してタコマージを行う場合（このストラテジーはそのようなマージに対して強制されます）および複数の追加の親は、マージの競合がある場合は中止され、まったくトレースを残しません。 --no-commitをタコマージと組み合わせようとしませんでしたが、論理的には、Gitで許可されている場合、2番目からN番目の親をMERGE_HEADに残します。

1頑固。

2
torek