web-dev-qa-db-ja.com

GitとMercurialを使用した部分クローン

GitとMercurialで1つのブランチのみ（または特定のコミットから）クローンを作成することはできますか？つまり、中央レポジトリを複製したいのですが、それは巨大なので、その一部だけを取得し、変更に貢献できるようにしたいのです。出来ますか？たとえば、タグ130以降のみが必要ですか？

もしそうなら、どのように？

gitmercurial
73
pablo

Gitの土地では、3つの異なるタイプの部分クローンについて話しています：

  • shallow clones：リビジョンポイントX以降の履歴が必要です。

    そのためにはgit clone --depth <n> <url>を使用しますが、浅いクローンは他のリポジトリとのやり取りが多少制限されていることに注意してください。パッチを生成して、電子メールで送信できます。

  • filepathによる部分クローン：いくつかのディレクトリ/pathのすべての改訂履歴履歴が必要です。

    Gitでは不可能。最新のGitでは、sparse checkoutを使用できます。つまり、履歴全体はありますが、すべてのファイルのサブセットのみをチェックアウト（作業領域に保持）できます。

  • 選択したブランチのみのクローン：1つのブランチ（または選択したブランチのサブセット）のみをクローンしたい。

    可能、および

    git 1.7.10以前は単純ではありません：クローンが行うことを手動で行う必要があります。つまり、git init [<directory>]、次にgit remote add Origin <url>、.git/configを*で置き換え、remote.Origin.fetchを置き換えます要求されたブランチ（おそらく「マスター」）、次にgit fetchによって。

    git 1.7.10時点git cloneは、この目的のために追加されたように思える --single-branch オプションを提供し、非常に簡単です。

    ただし、ブランチは通常、ほとんどの履歴を共有するため、ブランチのサブセットのみを複製することによる利益は、あなたが思っているよりも小さい可能性があることに注意してください。

ブランチの選択されたサブセットのみの浅いクローンを作成することもできます。

人々がファイルパス（同じリポジトリ内の複数のプロジェクト）で物事をどのように分解するかを知っている場合、サブモジュール（svn：externalsのようなもの）を使用して、リポジトリを別々にクローン可能な部分に事前分割できます。

75
Jakub Narębski

Mercurialの土地では、3つの異なるタイプの部分クローンについて話している：

  • 浅いクローン：リビジョンポイントX以降の履歴が必要ですremotefilelog extensionを使用します
  • ファイルパスによる部分クローン：experimental narrowhg extensionのディレクトリ/ pathのすべての改訂履歴が欲しい、またはディレクトリ/ pathのファイルだけを自分のディレクトリに入れたい実験的スパース拡張子を使用した作業ディレクトリ（バージョン4.3以降に出荷、hg help sparse）。
  • ブランチごとの部分クローン：ブランチYのすべての改訂履歴が必要です：use clone -r

人々がファイルパス（同じレポ内の複数のプロジェクト（あなたの恥））で物事をどのように分解するかを知っている場合、サブリポジトリ（svn externalsのようなもの）を使用してレポを別々にクローン可能な部分に事前分割することができます

また、「非常に巨大で、その一部だけを取得したい」ということに関しては、あなたは本当にそれを一度だけ行う必要があります。昼食を食べている間にそれをクローンするだけで、それからあなたはもっと永遠にそれを手に入れることができます。その後、pullを使用して、効率的にデルタを取得できます。また、別のクローンが必要な場合は、最初のクローンを複製するだけです。クローンを取得した場所は重要ではありません（また、ローカルクローンは裏側のハードリンクであるため、追加のディスク領域を占有しません）。

49
Ry4an Brase

選択した答えは良い概要を提供しますが、完全な例はありません。

ダウンロードとチェックアウトのフットプリントを最小限に抑える （a） 、 （b） ：

git clone --no-checkout --depth 1 --single-branch --branch (name) (repo) (folder)
cd (folder)
git config core.sparseCheckout true
echo "target/path/1" >>.git/info/sparse-checkout
echo "target/path/2" >>.git/info/sparse-checkout
git checkout

ローカルリポジトリのフットプリントを定期的に最適化します （c） （オプション、注意して使用）：

git clean --dry-run # consider and Tweak results then switch to --force
git gc
git repack -Ad
git Prune

参照： gitで大きなリポジトリを処理する方法

9
nobar

このメソッドは、サブリポジトリなしでバージョン管理されていないアーカイブを作成します。

hg clone -U ssh://machine//directory/path/to/repo/project projecttemp

cd projecttemp

hg archive -r tip ../project-no-subrepos

サブリポジトリのないバージョン管理されていないソースコードは、project-no-subreposディレクトリにあります。

5
rossmic

Gitについて、Linus Torvaldsが2007年に記録され、オンラインで利用可能な講演で概念的な観点からこの質問に答えたことは、歴史的に重要かもしれません。

問題は、Gitリポジトリから一部のファイルのみをチェックアウトできるかどうかです。

テクニカルトーク：git t = 43：10のLinus Torvalds

要約すると、彼は、Gitを他のソース管理システム（BitKeeperとSVNを引用）と区別するGitの設計上の決定事項の1つは、Gitがファイルではなくコンテンツを管理することだと言いました。その意味は、例えば2つのリビジョンのファイルのサブセットのdiffは、最初にdiff全体を取得してから、要求されたファイルにのみプルーニングすることによって計算されます。もう1つは、履歴全体をチェックアウトする必要があることです。全か無かの方法で。このため、大まかに関連するコンポーネントを複数のリポジトリに分割することを提案し、小さなリポジトリを保持するスーパープロジェクトとして構成されたリポジトリを管理するためのユーザーインターフェイスを実装するための継続的な取り組みについて言及します。

私が知る限り、この基本的な設計上の決定は、今日でもなお重要です。スーパープロジェクトのことは、おそらく現在の サブモジュール になりました。

2
user7610