web-dev-qa-db-ja.com

Mercurialで1つのリビジョンを選択する方法を教えてください。

Mercurial/TortoiseHgで、次の例を考えると、D、E、Fを使用せずにリビジョン「G」をレポAにマージする最も簡単な方法は何ですか（GはD、E、Fに依存しないと仮定）。

Repo A: A - B - C

Repo B (Clone of A) A - B - C - D - E - F - G

パッチが最善策ですか？

mercurialtortoisehgcherry-pick
69
Tom Hubbard

トンファは正しい。あなたが説明しているのは、「マージ」（または「プッシュ」または「プル」）ではありません。それは「チェリーピッキング」です。プッシュまたはプルは、すべての変更セットをあるリポジトリからまだそのリポジトリにない別のリポジトリに移動します。 「マージ」は2つの「ヘッド」を取り、それらを両方の組み合わせである新しいチェンジセットにマージします。

Gを実際に移動する必要があるが、D、E、Fを保持できない場合は、リポジトリAからGを「hg export」し、次にリポジトリAで「hg import」する必要があります。 Transplant extension は、同じ変更セットが複数回移動するのを避けるのに役立ついくつかの機能を備えたエクスポート/インポートのラッパーです。

ただし、、一般的にインポート/エクスポート、移植、チェリーピッキングを使用することの欠点は、祖先なしではGを実際に移動できないことです。 Mercurialでは、チェンジセットのnameは、その親のハッシュIDを含む 'hashid'であるためです。異なる親（Gの新しい親はCであり、Fではない）は異なるハッシュIDを意味するため、それはもうGではなく、Gの作業ですが、名前による新しいチェンジセットです。

Gを新しいものとして移動して、G '（ジープライム）と呼びましょう。一部の用途では大したことではありませんが、他の用途では大きなピタです。すぐにリポジトリBが新しいチェンジセットHを取得し、それを親の上に移動すると、ハッシュが異なるGからG 'に変更されます。これは、HがH 'として移動することを意味します-100個のチェンジセットが行の下にあり、レポAにD、E、Fを置くことができなかったため、すべてに対して異なるハッシュIDがあります。

物をレポAからレポBに移動する場合（以前の移動とは逆の方向）に、物事をさらに激しくすることができます。 AからBへの単純な 'hg Push'を行おうとすると、G（およびH 'および後続の子孫）を取得します。これは、レポBに既にあるチェンジセットの複製になります。

それでは、あなたの選択肢は何ですか？

  1. Do n't care。データはまだありますが、名前が異なる同じチェンジセットになり、2つのリポジトリ間での今後のやり取りの作業が増えます。それは間違っていません、それは多分少し不器用です、そして何人かの人々は気にしません。
  2. D、E、およびFのすべてをレポAに移動します。すべての変更セットが無害であり、すべての面倒を避ける場合は、すべての変更セットを移動できます。それらがそれほど無害でなければ、それらを移動してから「hg backout」を実行して、新しいチェンジセットHのD、E、Fの効果を元に戻します。
  3. 最初からGにもっと良い親子関係を与えてください。このルートに行くには遅すぎるので、これに言及するのは意味がありません（ 編集履歴 ）。変更セットGで作業する前にすべきことは、hg update C。 GがチェンジセットD、E、およびFに依存していない、または必要としない場合、それは彼らの子供ではありません。

代わりに最初にCに更新すると、次のようなグラフが表示されます。

A - B - C - D - E - F
          \
            G

その場合、この質問に対する全体の答えはhg Push -r G ../repoAとGは同じハッシュIDを維持したままきれいに移動し、D、E、およびFはそれと一緒に行きません。

UPDATE：

コメントで指摘したように。最新のMercurialでは、hg graftコマンドはこれを行うのに最適な方法です。

76
Ry4an Brase

一般的にチェリーピッキングを扱っているタイトルを参照して、インターネット検索エンジンが一般的にチェリーピッキングのために人々をここに連れてくるかもしれないので、1つのレポで作業する例を示します。 1つのリポジトリで作業する場合、 hg graft を使用して実行します。

hg update C
hg graft G

結果は次のとおりです。

            G'
          / 
A - B - C - D - E - F - G

追加の警告：2つの変更セットは同じファイルに対する独立した並行コミットとして扱われ、マージの競合が発生する可能性があるため、ブランチ管理では一般にチェリーピッキングを避ける必要があります。たとえば、Gが1.0.1としてブックマークされた安定バージョンのブランチに適用されるバグ修正である場合は、mergefreezeブランチを使用し、masterブランチをfreezeブランチのバグ修正と時々マージします。

42
Iodnas