ローカルオブジェクトで完了したGit pushの解決方法

Question

私はgitを数年間使用していましたが、私のローカルgitは最近新しいメッセージを生成しています（私はリポジトリの成長により推測しています）。

私はGitHubの上で私のリモートにgit pushを行うと、私は（ほとんどの部分は非常に自然な、）次のような出力が得られます。

Counting objects: 99, done 
Delta compression using up to 4 threads. 
Compressing objects: 100% (97/97), done. 
Writing objects: 100% (99/99), 10.16 KiB | 0 bytes/s, done. 
Total 99 (delta 66), reused 0 (delta 0) 
remote: Resolving deltas: 100% (66/66), completed with 12 local objects 

私が興味の特定の部分がcompleted with n local objectsあり、い最近登場し始めたばかりです。ほとんどの場合、リポジトリはかなり良いクリップ（LoCとコミットカウントの両方）で成長しているので、私はこのメッセージにそれが関係していると仮定していますが、その場合はわかりません。

私はこれがエラーではないことを認識しています（私のgit pushは正常に動作しています）。しかし、私はこのメッセージの起源と意味について興味があり、なぜ数字がカウント/計算されているオブジェクトの実際の数。

Answer 1

Bryan Pendleton's commentには正しい答えがあります。git pushは「薄いパック」となりました。スマートプロトコル上のフェッチおよびプッシュ操作はすべて、シンパックを常に使用してネットワークトラフィックを最小限に抑えます。

すべてのパックファイルはdelta compressionを使用します。通常のGitパックファイルでは、同じパック内の他のオブジェクトに対してデルタ圧縮されたオブジェクトのみが圧縮されます（これらの他のオブジェクトもデルタで圧縮されますが、同じパック内のさらに多くのオブジェクトに対してのみ圧縮されます）。 「シンパック」は、意図的にこのルールに違反するパックファイルです。他の場所に格納されている他のオブジェクト（ルーズまたはパック）に対してデルタ圧縮します。細いパックを受け取ったGitは、薄いパックを欠落したオブジェクトで「肥やし」て「修正」するか、単に破棄します（薄いパックを個々のデルタ圧縮されたオブジェクトに分解する）。

Gitと他のGitがギガバイトのデータを送信しようとしているとします（しかし、多くのファイルでは単純化のために1としましょう）。しかし、2つのGitは既にギガバイトのファイルデータを持っています。 「古いデータをコピー途中からの手紙aを削除し、代わりにtheを挿入」、または同等に短くて単純なもの：新しいデータは、として表すことができます。 Gitが送信を行っていることを言っデルタ圧縮されたオブジェクトになり方「で1つのバイトを削除し、ハッシュ時間でオブジェクトから始まるが、Xオフセット、3バイトtheを追加でXオフセット」。このデルタ圧縮されたオブジェクトは、大部分のCPU時間を要します。結果として得られるパックファイルは非常に小さく、マイクロ秒単位でワイヤを横断します。受信側のGitは、欠落している1GBオブジェクトを追加することでそれを縮め、転送が完了します。この特定のケースで

、completed with 12 local objectsは薄いパックは、あなたのGitはあなたがすでに持っていた彼らのGitリポジトリを告げた12個のオブジェクトに依存していたことを意味します。 GitのDAGのため、あなたのGitはあなたがこれらのオブジェクトを持っていることをGitに伝えることができます。ハッシュID：Cコミットすると、コミットするすべてのツリーとブロブがあります。Cあなたも「浅い」リポジトリ-あなたを持っていないよう-asは長いはCをコミットするすべての祖先を持っている、そして先祖が犯したものとなっあらゆるツリーとブロブ。

この種の圧縮は、グラフ理論の直接的な結果です。それはまた、非常に大規模なプロジェクトであっても、最初のクローンは遅くなるかもしれませんが、ほとんどのgit fetchアップデートは非常に高速になる傾向があります。このルールの主な例外は、以前のデータオブジェクトに対してデルタ圧縮をうまく行えないGitデータオブジェクトを与えるときです。これには、すでに圧縮されたバイナリファイル（JPGイメージや圧縮されたtarballなど）が含まれます。 （皮肉なことに、Gitの修正されたxdeltaは、私が過去にテストしたいくつかのケースでは素晴らしい仕事をしなかったが、圧縮されたtarballは、理論上少なくとももっと圧縮することができた。）