回答:
ショートバージョン：それはそれが言うことを意味し、あなたがそれをただ終わらせれば、すべてがうまくいくでしょう。
リポジトリ内のルーズな（アンパックされた）オブジェクト（プッシュを含む）の数を潜在的に増やす可能性があるほとんどの操作中に、Gitはを呼び出しますgit gc --auto。十分なルーズオブジェクト（デフォルトでは、少なくとも6700）がある場合は、オブジェクトgit repack -d -lをパックするために呼び出されます。個別のパックが多すぎる場合は、1つに再パックされます。
パックは、多数のオブジェクトを含む、デルタ圧縮された単一のファイルです。オブジェクトをパックに格納する方が効率的ですが、オブジェクトをパック（圧縮）するには時間がかかるため、Gitは最初にルーズオブジェクトを作成し、次にバッチでそれらをパックし、次にを自動呼び出ししますgit gc --auto。
Gitに再パックを完了させた場合、これはしばらくの間起こりません。特に大きなバイナリオブジェクトがたくさんある場合は特に時間がかかりますが、トリガーされている場合は、リポジトリによって使用されるディスク領域の量が大幅に削減される可能性があります。本当にそうしたくない場合は、configパラメータを変更できますgc.auto。6700をはるかに超える値に増やすと、発生頻度は低くなりますが、発生する時間が長くなります。これを減らしても、現在のリパックを実行する必要がありますが、その後、より頻繁に発生し、より速く終了します。0に設定すると、自動再パッキングが無効になります。
詳細については、man git-gc（下--auto）およびman git-config（下gc.auto）を参照してください。
fatal: Out of memory, malloc failed (tried to allocate 79610689 bytes) error: failed to run repack--これは、コードベース全体を1つのgitリポジトリに固定するために得られるものです。アプリを強制終了し、「手動」で強制的に再パックするつもりです
Jefroniは正解ですが、自動パッキングが完了するまでに時間が必要な場合もありますが、自動パッキングメッセージがOPで説明されているように数日間続く場合は、この質問で説明されているように、gitのクリーンアップでダングリングオブジェクトが欠落している可能性があります。
ダングリングオブジェクトが自動パッキングに関する継続的なメッセージをトリガーしているかどうかを確認するには、を実行してみてくださいgit fsck。ダングリングコミットの長いリストを取得した場合は、
git gc --prune=now
通常、1回のプルで自動パッキングメッセージが消えない場合は、2〜3か月ごとにリポジトリでこれを実行する必要があります。
git pull数日にわたってを実行するたびにメッセージが表示され、fsck確かに大量のぶら下がりコミットが表示されました。
1つのプロジェクトで無効にするには：
cd your_project_dir
git config gc.auto 0
グローバルに無効にするには：
git config --global gc.auto 0
うまくいけば、そのgit gc --autoステップは今より効率的です（git 2.0.1、2014年6月25日）。NguyễnTháiNgọcDuyによるコミット62aad18を
参照してください（）pclouds
gc --auto：バックグラウンドで参照をロックしません9f673f9（
gc：バックグラウンドで--autoを実行するための構成オプション-2014-02-08、Git 2.0.0）はgc --auto、ユーザーの待機時間を短縮するために" "をバックグラウンドで配置します。
ガベージコレクションの一部は、pack-refsとpruning reflogsです。これらは一部の参照をロックする必要があり、同じ参照をロックしようとする他のプロセスを中止する場合があります。
gc --autoがスクリプトの途中で発生した場合、gcがバックグラウンドでロックを保持していると、スクリプトが失敗する可能性があります。これは、9f673f9より前に発生することはありませんでした。並行して実行
pack-refsしreflog --prune、フォアグラウンドで" "を実行して、並列参照の更新を停止します。残りのバックグラウンド操作（リパック、プルーニング、リアー）は、実行中のgitプロセスに影響を与えません。
Git 2.22（2019年第2四半期）ではさらに最適化されていgit gcます。