MacでGITを使用しています。十分に言った。私にはツールがあり、経験があります。そして、私はそれを使い続けたいです。ここには戦争はありません...
問題は常に相互運用性にあります。ほとんどの人がSVNを使用していますが、これは私にとって素晴らしいことです。 Git SVNはそのまま使用でき、簡単なソリューションです。人々は喜んでSVNを使い続けることができ、ワークフローもツールも失うことはありません。
今... Mercurialと一緒にやってくる人もいます。彼らにとっては素晴らしいことです。彼らには理由があります。しかし、すぐに使用できるGIT HGは見つかりません。 HGに切り替えたくはありませんが、それらのリポジトリと相互運用する必要があります。
誰もがこれの簡単な解決策を知っていますか?
2012年6月からの更新。現在、開発者がgit側から作業したい場合、Git/Hgの相互運用性のために以下の方法があるようです。
Mercurialと hg-git extension をインストールします。後者は、パッケージマネージャーを使用するか、easy_install hg-git
を使用して実行できます。その後、以下が〜/ .hgrcにあることを確認してください。
[extensions]
hggit =
ここでbookmarks
拡張機能の指定について言及しているリファレンスもありますが、これはv 1.8以降Mercurialに組み込まれています。 Windowsでのhg-gitのインストールに関するヒント です。
Hg-gitを入手したら、おおよそ Abderrahim Kitouniの投稿 のようなコマンドを使用できます。このメソッドは、2009年以来 refined and tweaked であり、フレンドリーなラッパーがあります: git-hg-again 。これは、MercurialとGitの両方の作業ディレクトリとしてトップレベルディレクトリを同時に使用します。 Mercurialリポジトリのdefault
(名前のない)ブランチの先端と同期するMercurialブックマークを作成し、そのブックマークからローカルGitブランチを更新します。
git-remote-hg は、Mercurial hg-git
拡張にも基づいた異なるラッパーです。これは、さらにgit-remote-helpers
プロトコルを使用します(そのため、その名前です)。 Git作業ディレクトリに対してのみトップレベルディレクトリを使用します。 Mercurialリポジトリを公開しません。また、GitとMercurialの間の同期をより安全で慣用的にgitlikeにするために、2番目のベアGitリポジトリを維持します。
git-hg スクリプト(以前のメンテナンス here )は、hg-fast-export
に基づいて異なる方法を使用します fast-exportプロジェクト から。方法2のように、これはまた、裸のMercurialリポジトリと追加の裸のGitリポジトリを保持します。
プルの場合、このツールはMercurialブックマークを無視し、代わりにすべての名前付きMercurialブランチをGitブランチにインポートし、デフォルトの(名前のない)Mercurialブランチをmasterにインポートします。
一部の解説では、このツールはhg-> gitのみであると説明していますが、2011年12月7日にgit-> hg Pushサポートに統合されたと主張しています。 これらのツールのレビュー このツールがプッシュサポートを実装しようとする方法は機能しないようです。
git-remote-hg という別のプロジェクトもあります。上記のバージョンとは異なり、このバージョンはhg-gitに依存せず、代わりにMercurial Python APIに直接アクセスします。現時点では、Gitのパッチバージョンも必要です。まだこれを試していません。
最後に、 Tailor は、さまざまな異なるVCS間で段階的に変換するプロジェクトです。これの開発は積極的に続けられないようです。
これらのアプローチの最初の3つは、調査するように私を説得するのに十分に軽量に見えました。私はセットアップで実行するためにいくつかの方法でそれらを微調整する必要があり、それらを改善するためにさらに微調整するいくつかの方法を見た後、評価することができるようにそれらをさらに調整してお互いをより似たように動作させましたより効果的に。それから私は、他の人も同じ評価をするためにこれらの微調整を好むかもしれないと思った。 ソースパッケージを作成 を使用すると、最初の3つのツールのいずれかのバージョンをインストールできます。また、必要なhg-fast-export
ピースのインストールも処理する必要があります。 (自分でhg-git
をインストールする必要があります。)
それらを試してみて、何が最適かを自分で決めることをお勧めします。これらのツールが壊れるケースについて聞いてうれしいです。それらをアップストリームの変更と同期させ、アップストリームの作成者が私が有用だと思う微調整を確実に認識できるようにします。
上記で述べたように、これらのツールを評価する際、git-hg
はプッシュではなくMercurialからのプルにのみ使用できるという結論に達しました。
関連して、GitとMercurialの便利な比較/翻訳マニュアルを次に示します。Gitを既に知っているユーザーを対象とする場合もあります。
ネイティブサポートを提供する新しいgit-remote-hgがあります。
GitでのMercurialおよびBazaarのブリッジサポート
git-remote-hg を$ PATHにコピーして、実行可能にします。依存関係はありません(Mercurial以外):
git clone hg::https://www.Mercurial-scm.org/repo/hg/
ネイティブGitリポジトリであるかのように、そこからプッシュおよびプルできるはずです。
新しいGitブランチをプッシュすると、それらのMercurialブックマークが作成されます。
詳細については、 git-remote-hg wiki を参照してください。
hg-git を使用できるはずです。
hg clone <hg repository>
編集~/.hgrc
および追加:
[extensions]
hgext.bookmarks =
hggit =
gitにmaster
が含まれるようにブックマークを作成します。
cd <repository>
hg bookmark -r default master
編集.hg/hgrc
リポジトリに追加します:
[git]
intree = true
これでgitリポジトリを作成できます:
hg gexport
結果のディレクトリをgit cloneとして使用できます。 Mercurialからのプルは次のようになります。
hg pull
hg gexport
mercurialにプッシュする:
hg gimport
hg Push
(はい、このワークフローではhgを使用する必要がありますが、ハッキングはすべてgitで行われます)
追伸このワークフローに問題がある場合は、バグを報告してください。
あなたが試すことができます hg2git
、pythonスクリプトであり、 http://repo.or.cz/w/fast-export.gitで見つけることができるfast-exportの一部です。 。
ただし、Mercurialをインストールする必要があります。
Hg-gitはtwo-wayブリッジであるため、変更セットをGitからMercurialにプッシュすることもできます。
Hg-Git Mercurialプラグイン 。自分で試したことはありませんが、チェックアウトする価値があるかもしれません。
https://github.com/cosmin/git-hg のgit-hg
で大きな成功を収めました(hg
のインストールも必要です)。フェッチ、プル、 押す hg-git
(hg
からgitへの類似機能)よりも安定しています。
使用例については、 https://github.com/cosmin/git-hg#usage をご覧ください。ユーザーインターフェイスはgit-svn
に非常に似ています。
git-hg
では、複製されたhgリポジトリごとに追加のディスク領域が必要です。実装では、完全なMercurialクローン、追加のgit bareクローン、および実際のgitリポジトリを使用します。必要なディスク容量は、通常のgitのみの使用量の約3倍です。追加のコピーは、作業ディレクトリの.git
ディレクトリ(または通常どおりGIT_DIR
が指す場所)の下に保存されます。
注意:git-hg
が解決しようとする基本的な問題は、git
機能とhg
機能の間に1:1マッピングがないことです。最大の問題は、gitブランチとhg名前のないブランチおよびhg名前付きブランチおよび間のインピーダンスの不一致ですhg bookmarks(これらはすべてgit
ユーザーへのブランチのように見えます)。関連する問題は、デフォルトでブランチ名がテンプレートコミットメッセージにのみ追加されるgitではなく、hg
がバージョン履歴に元の名前付きブランチ名を保存しようとすることです。
git
とhg
の間に相互運用可能なブリッジを作成すると主張するツールは、このインピーダンスマッチをどのように処理するかを説明する必要があります。その後、選択したソリューションがニーズに合うかどうかを判断できます。
git-hg
が使用する解決策は、すべてのhgブックマークを破棄し、名前付きブランチをgitブランチに変換することです。さらに、git masterブランチをデフォルトの名前のないhgブランチに設定します。
Hggitを試しました。 git'ersとhg'ersの仕事に対処しなければならないので、私のために働きます。特にレビューの場合、これは素晴らしいことです。
そのトピックに関する軽微な問題/警告:
安定したLinuxカーネルリポジトリをhgでクローンしようとしました。これらのリポジトリはgitで管理されており、通常は多数のファイルが含まれています。
とても遅かった。完全にクローンを作成するのに2日かかりましたand作業コピーを更新します。
私は cosmin's git-hg と abourget's git-hg-again の両方を試しました mutt's hg repo 、それは後でマージも、前者は少しランダムです。以下のスクリーンショットから見ることができます。
上記からわかるように、 abourgetのgit-hg-again による2番目のグラフは、元のhgkグラフに非常に近く、実際にはmuttの実際のワークフローを反映しています。
私が見つけたgit-hg-againの欠点の1つは、「hg」リモートを追加せず、そのすべての参照をローカルタグとしてインポートすることです。
サービス Git-hg Mirror を使用すると、双方向のhg-git(およびgit-git、hg-hg)同期も可能です。舞台裏でhg-gitを使用し、コードもオープンソースです。
免責事項:私はその背後にある会社から来ました。