致命的：早い EOF fatal：index-packが失敗しました
私はグーグルで多くの解決策を見つけましたが、どれも私のために働きません。
LANネットワークにあるリモートサーバーに接続して、1台のマシンからクローンを作成しようとしています。
他のマシンからこのコマンドを実行するとエラーが発生します。
しかし、git：//192.168.8.5 ...を使用してSAME cloneコマンドを実行しても問題ありません。
何か案は ？
user@USER ~
$ git clone -v git://192.168.8.5/butterfly025.git
Cloning into 'butterfly025'...
remote: Counting objects: 4846, done.
remote: Compressing objects: 100% (3256/3256), done.
fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s
fatal: early EOF
fatal: index-pack failed
私はこの設定を.gitconfigに追加しましたが、助けにもなりません。
gitバージョン1.8.5.2.msysgit.0を使う
[core]
compression = -1
まず、圧縮を無効にします。
git config --global core.compression 0
次に、情報量を切り捨てるために部分クローンを作成しましょう。
git clone --depth 1 <repo_URI>
それがうまくいったら、新しいディレクトリに移動し、クローンの残りの部分を取得します。
git fetch --unshallow
あるいは、
git fetch --depth=2147483647
それでは、定期的に引っ張ってください。
git pull --all
私はこれらの症状を悪化させるような1.8.xバージョンのmsysgitとのグリッチがあると思うので、別の選択肢はgitの以前のバージョンで試すことです（<= 1.8.3、私は思う）。
このエラーはgitのメモリニーズに対して発生するかもしれません。この問題を解決するために、.gitconfigの$USER_HOMEであるグローバルgit設定ファイルにこれらの行を追加することができます。
[core]
packedGitLimit = 512m
packedGitWindowSize = 512m
[pack]
deltaCacheSize = 2047m
packSizeLimit = 2047m
windowMemory = 2047m
ついにgit config --global core.compression 9によって解決されました
私はほぼ5回試しました、そしてそれはまだ起こります。
それから私はより良い圧縮を使用しようとしました、そしてそれはうまくいきました！
git config --global core.compression 9
core.compression
デフォルトの圧縮レベルを示す整数-1..9。 -1がzlibのデフォルトです。
0は圧縮なしを意味し、1..9はさまざまな速度とサイズのトレードオフ、9は最も遅いものです。
設定されていると、core.looseCompressionやpack.compressionなどの他の圧縮変数にデフォルト値を提供します。
@ingyhereが言ったように：
シャロークローン
まず、圧縮を無効にします。
git config --global core.compression 0
次に、情報量を切り捨てるために部分クローンを作成しましょう。
git clone --depth 1 <repo_URI>
それがうまくいったら、新しいディレクトリに移動し、クローンの残りの部分を取得します。
git fetch --unshallow
あるいは、
git fetch --depth=2147483647
それでは、引っ張ってください。
git pull --all
それからあなたの地元の支店だけの追跡マスターの問題を解決するために
あなたのgit設定ファイル（.git/config）をあなたが選んだエディタで開いてください。
それが言うところ：
[remote "Origin"]
url=<git repo url>
fetch = +refs/heads/master:refs/remotes/Origin/master
行を変える
fetch = +refs/heads/master:refs/remotes/Origin/master
に
fetch = +refs/heads/*:refs/remotes/Origin/*
Gitフェッチを実行すると、Gitはリモートブランチをすべて引っ張ります。
私の場合、これはとても役に立ちました。
git clone --depth 1 --branch $BRANCH $URL
これはチェックアウトを言及されたブランチだけに制限するでしょう、そしてそれ故にプロセスをスピードアップするでしょう。
これが役立つことを願っています。
Gitがメモリを使い果たしたとき、私はこのエラーを得ました。
メモリを解放し（この場合はコンパイルジョブを終了させる）、もう一度試すとうまくいきました。
私はすべてのコマンドを試してみましたが、私にはうまくいきませんが、うまくいったのはgit_urlを代わりにhttpに変更することでしたssh
クローンコマンドがあれば：
git clone <your_http_or_https_repo_url>
それ以外の場合は、既存のリポジトリを利用する場合は、
git remote set-url Origin <your_http_or_https_repo_url>
これが誰かに役立つことを願っています！
私の場合、それは接続の問題でした。私はリソースへのアクセスが制限されていた内部のWiFiネットワークに接続していました。それはgitにフェッチをさせていましたが、ある時にクラッシュしました。これは、ネットワーク接続に問題がある可能性があることを意味します。ウイルス対策、ファイアウォールなど、すべてが正常に動作していることを確認します。
Sshはダウンロードのパフォーマンスを向上させ、ネットワークの問題を回避できるため、elin3tの答えは重要です。
以前の回答では、512mに設定することを推奨しています。 64ビットアーキテクチャでは逆効果だと考える理由があると思います。 core.packedGitLimitのドキュメント は次のとおりです。
デフォルトは、32ビットプラットフォームでは256 MiB、64ビットプラットフォームでは32 TiB（事実上無制限）です。これは、最大のプロジェクトを除き、すべてのユーザー/オペレーティングシステムにとって妥当なものでなければなりません。おそらく、この値を調整する必要はありません。
試してみたい場合は、設定しているかどうかを確認してから、設定を削除してください。
git config --show-Origin core.packedGitLimit
git config --unset --global core.packedGitLimit
Git 2.13.x/2.14（2017年第3四半期）は、core.packedGitLimitに影響を与えるデフォルトのgit fetchを上げることに注意してください。
デフォルトのパックgit制限値は、より大きなプラットフォームで引き上げられました（8 GiBから32 GiB） 「gc」が並行して実行されている間に（回復可能な）障害から「git fetch」を保存する。
commit be4ca29 （2017年4月20日）by David Turner（csusbdt） を参照してください。
サポート： ジェフ・キング（peff） 。
（2017年5月16日 commit d97141b で J浜野順夫-gitster- に合併）
core.packedGitLimitを増やす
core.packedGitLimitを超えると、gitはパックを閉じます。
フェッチと並行してリパック操作が行われている場合、フェッチによってパックが開かれ、packedGitLimitがヒットしたために強制的に閉じることがあります。
その後、リパックはフェッチの下からパックを削除し、フェッチが失敗する可能性があります。これを防ぐには、
core.packedGitLimitのデフォルト値を増やします。現在の64ビットx86_64マシンでは、48ビットのアドレス空間が利用可能です。
64ビットARMマシンには標準のアドレススペースがない（つまり、メーカーによって異なる）ようであり、IA64およびPOWERマシンにはフル64ビットがあります。
したがって、合理的に注意できるのは48ビットのみです。カーネルの使用のために48ビットのアドレス空間のいくつかのビットを予約し（これは厳密には必要ではありませんが、安全である方が良いです）、残りの45まで使用します。
Gitリポジトリはすぐにこの大規模な場所の近くに配置されることはないため、これにより障害を防ぐことができます。
ここで答えのほとんどを試してみました、私は PuTTY SSHクライアント すべての可能な星座でエラーを得ました。
OpenSSHに切り替えたら エラーが消えました（環境変数GIT_SSHを削除し、git bashを再起動してください）。
私は新しいマシンと最新のgitバージョンを使っていました。他の多くの古いマシン（AWSも同様）では、PuTTYでもgit設定なしで期待通りに動作しました。
私は同じ問題を抱えています。上記の最初のステップに従って、私はクローンを作ることができました、しかし、私は他に何もすることができません。古いブランチを取得、取得、またはチェックアウトできません。
各コマンドは通常よりもずっと遅く実行され、その後オブジェクトを圧縮した後に終了します。
I:\dev [master +0 ~6 -0]> git fetch --unshallow
remote: Counting objects: 645483, done.
remote: Compressing objects: 100% (136865/136865), done.
error: RPC failed; result=18, HTTP code = 20082 MiB | 6.26 MiB/s
fatal: early EOF
fatal: The remote end hung up unexpectedly
fatal: index-pack failed
あなたの参照があまりにも多くのメモリを使用しているときにもこれが起こります。メモリを刈り込むことでこれが解決しました。フェッチするものに制限を加えるだけです - >
git fetch --depth=100
これによりファイルが取得されますが、過去100回の編集が履歴に含まれています。この後は、通常の速度で任意のコマンドを実行できます。
同じ問題が発生しました。 REPOは大きすぎてSSH経由でダウンロードできませんでした。 @ elin3tが推奨するように、HTTP/HTTPSでクローンを作成し、SSH REPOを使用するように。git/configのREMOTE URLを変更しました。
Git-daemonの問題は v2.17.0 で解決されたようです（動作しないv2.16.2.1で検証済み）。すなわち「出力バッファをロックする」ためにコンソールでテキストを選択するという回避策はもう必要ではありません。
からhttps://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt ：
- "gitデーモン"の各種修正（後でed15e58efe jk/daemon-fixesをmaintにマージします）。
私の場合は、プロトコルがhttpsのときには何もうまくいきませんでした。それから私はsshに切り替えて、確実に履歴全体ではなく、特定のブランチからリポジトリを取り出しました。これは私を助けました：
git clone --depth 1 "ssh：.git" --branch“ specific_branch”
その間に行っていたすべてのダウンロードをオフにしたため、スペースが多少解放され、帯域幅が上下した
ドライブに十分な空き容量があることを確認してください。
git pullを実行すると、以下と同じ問題が発生しました
remote: Counting objects: 149, done.
Connection to git-codecommit.us-east-1.amazonaws.com closed by remote Host.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
次に、git statusを確認しました。非常に多くのコミットされていない変更があったため、コミットおよびプッシュすべてのコミットされていない変更によって問題を修正しました。