3

私のシナリオは次のとおりです。

私が複製したプロジェクトは、もともと Mercurial を使用してバージョン管理されていたもので、その元のレポの複製とそのすべての履歴があります。ある時点で、プロジェクトの所有者は GitHub に移行することを決定しましたが、移行のすべての履歴を失ったため、この新しいリポジトリは古いプロジェクトの継続ですが、リビジョン 0 から事実上新たに開始しています。

Hg に固執したいのですが、Hg-Git を使用すると明らかに Git リポジトリからプルできますが、Hg リポジトリの先頭と Git リポジトリの末尾をくっつける方法がわからないので、以前と同じように、定期的な更新を引き続けることができます。Hg リポジトリの先頭に一致する Git での実際のコミットは最初のコミットではないため、尾の先端ではありません。

hg convert と --splicemap が役立つかもしれないと思ったのですが、それについて読めば読むほど、私にとっては解決策とは思えなくなりました。

どうすればこれを達成できるかについて、誰かが提案できますか?


更新
同様のことをしようとしているかもしれない人の情報のために、私は最終的に私が望んでいた結果を達成することができましたが、それは長く曲がりくねった道でした。

  1. hg-git プラグインを使用して Github から Git リポジトリを取得しました。
  2. 次に、それを新しいリポジトリに複製し、関連するが切断された Hg リポジトリの内容をhg pull --forceを使用してプルしました。
    これで、レポに関する限り共通の祖先を持たない 2 つの異なる開発ブランチを持つレポができました。これをhydraと呼びます。
  3. hg convertsplicemapを使用して、履歴の一致するポイントでブランチを新しいレポに結合し、hg stripを実行して不要なビットを取り除きました。
  4. ただし、トリックは、元の Git リポジトリが更新されるということでした。この結合されたリポジトリに新しい変更を取り込めるようにしたかったのです。
    ソリューション?バッチ ファイル。
    そうですね、バッチ ファイルです。
    解決策は実質的に 3 つのセットでした。まず、Github から Git リポジトリを保持するリポジトリにプルします。2 番目は Git リポジトリから hydra にプルされます (Hg ソースは変更されないため、そこから再度プルする必要はありません)。3 番目にhg convertコマンドを再実行して、結合されたリポジトリを hydra からの新しい情報で更新します。

それは不快で、長々としたもので、設定するのは少し悪夢のようなものでしたが、今では問題なく動作し、最終的なレポは予測可能で妥当なサイズです.

4

1 に答える 1

3

これを試したことはありませんが、bridge-repo の /.hg にある git-mapfile を操作するとうまくいく可能性があります。私は次のように試してみます:

  1. Hg リポジトリのヒントが Git リポジトリのルートであるとしましょう。
  2. hg-git を介して Git リポジトリのクローンをルートまでのみ作成します (Git では可能ですよね?)。
  3. 元の Hg リポジトリからすべてのコミットを hg-git クローンにプルします。
  4. 唯一のルートを取り除きますが、このルートの完全なハッシュを書き留めます。
  5. Hg リポジトリのヒントの完全なハッシュを書き留めます (現在は hg-git クローンのヒントでもあります)。
  6. /.hg/git-mapfile を編集します。片側に孤立ルートのハッシュを持つエントリを 1 つだけ含める必要があります (右側にある必要があります)。このハッシュをヒントのハッシュに置き換えます。反対側 (左) は、対応する Git コミット オブジェクトのハッシュであるため、置き換えないでください。
  7. 「HGプル」。理論が成り立つ場合、これにより新しい Git ノードが古い Hg ノードに追加されます。

完全にばかげているかもしれませんが、少なくとも hg-git の古い (「愚かな」) バージョンは、このマップ ファイルを介して必要な git オブジェクトを単純に決定していました。だから試してみる価値はあるだろう...

于 2013-06-26T18:20:55.713 に答える