したがって、git 共有リポジトリは、大きな BLOB を含むフォルダーを同期させるのにほぼ最適であるようです。コンピューター間で配布したい写真やビデオが 700 GB ほどありますが、git のみを使用すると、実際には必要のないディスク使用量のオーバーヘッドが大量に発生します。
さて、--shared (または -s) でクローンすると、ローカルオブジェクトストレージのない Git リポジトリが提供されます (正しく理解していれば)。これは私が必要としているものです。しかし、ドキュメントは「クローンするリポジトリがローカルマシン上にある場合...」で始まります。clone -s は SSH 経由でも同じように機能しますが、クローンするリポジトリがローカルマシン上にある場合はどうなるのか疑問に思います。ないローカルマシンで。-s のドキュメントはこの文で始まるので、そのケース全体がカバーされていないように感じます。リモート側でコミットを削除する以外に、特定のオブジェクト (ローカルでまだ使用されている可能性があります) がガベージ コレクションされる可能性があることに注意する必要があることはありますか? (サーバーでベア リポジトリを使用したいので、いずれにしても発生しません)
答え1
私は git が大好きですが、残念ながら、git はこのタスクに適したツールではありません。
Git は、主にテキスト コンテンツのリポジトリの変更履歴を非常に効率的に保持するように設計されています。Git はバイナリの保持をサポートしていますが、任意のリビジョンにチェックアウトできるようにバイナリを履歴に永久に保存する必要があり、ディスク領域の面で非常にコストがかかります。
また、バイナリが圧縮可能ではないと仮定すると (画像、動画、音楽など)、git オブジェクト ストアのサイズはツリーのチェックアウトとほぼ同じになります。言い換えると、700 GB 相当の元のファイルの場合、オブジェクト ストア (.gitディレクトリ) はほぼ同じ量を消費し、コミット (コンテンツの追加と削除) を開始するとさらに消費します。
いわゆるシャロー クローンを使用できます。これは、オブジェクトの最後のリビジョンのみをオブジェクト ストアに保持しますが、シャロー リポジトリはクローンのみ可能で、コミットすることはできません。この場合、マスター Git リポジトリは通常 (シャローではない) である必要があり、依然として大きくなりますが、すべてのシャロー クローンは適切なサイズになります。
おそらく、rsync のようなより単純な同期スキームを維持したほうがよいでしょう。ただし、その場合、履歴を確認する機能が失われます。無料のランチはありません :(
答え2
これはあなたの質問に対する答えではないことは承知していますが...rsync2 つのフォルダーを同期させるのがはるかに簡単になりますか?