致命的：初期EOF致命的：インデックスパックが失敗しました

私はグーグルして多くの解決策を見つけましたが、どれもうまくいきません。

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

BitBucket発行スレッドから：

私はほぼ5回試しましたが、それはまだ起こります。

次に、より良い圧縮を使用してみましたが、うまくいきました！

git config --global core.compression 9

Gitドキュメントから：

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 configファイルを開きます（.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 fetchを実行すると、gitがすべてのリモートブランチをプルします

私の場合、これは非常に役に立ちました：

git clone --depth 1 --branch $BRANCH $URL

これにより、チェックアウトが上記のブランチのみに制限されるため、プロセスが高速化されます。

これがお役に立てば幸いです。

私はそのすべてのコマンドを試しましたが、どれもうまくいきませんでしたが、うまくいったのはgit_urlをsshではなくhttpに変更することでした

クローンコマンドの場合：

git clone <your_http_or_https_repo_url> 

それ以外の場合、既存のリポジトリを利用している場合は、

git remote set-url origin <your_http_or_https_repo_url>

これが誰かを助けることを願っています！

gitがメモリ不足になると、このエラーが発生しました。

一部のメモリを解放して（この場合は、コンパイルジョブを終了させます）、もう一度試すとうまくいきました。

私の場合、それは接続の問題でした。私は内部wifiネットワークに接続していましたが、そこではリソースへのアクセスが制限されていました。それはgitにフェッチをさせることでしたが、ある時点でクラッシュしました。これは、ネットワーク接続の問題である可能性があることを意味します。ウイルス対策、ファイアウォールなど、すべてが適切に実行されているかどうかを確認します。

sshはダウンロードのパフォーマンスを向上させ、ネットワークの問題を回避できるため、elin3tの答えは重要です。

以下の設定ではうまくいきません。

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

以前のコメントのように、それはgitからのメモリの問題かもしれません。したがって、私は作業スレッドを減らしようとします（32から8に）。同時にサーバーから多くのデータを取得しないようにします。次に、「-f」を追加して、他のプロジェクトを強制的に同期させます。

-f: Proceed with syncing other projects even if a project fails to sync.

その後、正常に動作します。

repo sync -f -j8

以前の回答では、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（Q3 2017）デフォルト上げないことcore.packedGitLimitの影響git fetch：
デフォルトはパック-gitの限界値が（大きなプラットフォーム上で提起された8ジブから32ジブに）「保存するgit fetch（回復可能）障害からの」 「gc」が並行して実行されています。

David Turner（）によるcommit be4ca29（2017年4月20日）を参照してください。 協力者：ジェフキング（）。^{（による合併Junio C浜野- -にd97141bコミット、2017年5月16日）を}csusbdt
peff
gitster

増加する core.packedGitLimit

ときcore.packedGitLimitを超えている、gitがパックを閉じます。
フェッチと並行して行われる再パック操作がある場合、フェッチによりパックが開かれ、packedGitLimitにヒットしたために強制的に閉じられる場合があります。
再パックすると、フェッチの下からパックが削除され、フェッチが失敗する可能性があります。

増加する core.packedGitLimitこれを防ぐには、のデフォルト値をてください。

現在の64ビットx86_64マシンでは、48ビットのアドレス空間を使用できます。
64ビットのARMマシンには標準的な量のアドレス空間がない（つまり、製造元によって異なる）ようであり、IA64およびPOWERマシンには完全な64ビットがあります。
したがって、48ビットは、私たちが気にすることができる唯一の制限です。カーネルで使用するために48ビットアドレス空間のいくつかのビットを予約し（これは厳密には必要ではありませんが、安全であることが望ましいです）、残りの45まで使用し
ます。gitリポジトリは、この大きな近くにいつでもありません。すぐに、これは失敗を防ぐはずです。

@cmpickleの回答を使用して、クローンプロセスを簡略化するスクリプトを作成しました。

ここでホストされています： https //gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

次の行を使用して実行できます。

curl -sL https://git.io/JvtZ5 | sh -s repo_uri repo_folder

私の場合、問題はgit構成パラメーターのどれでもありませんでしたが、私のリポジトリには、システムで許可されている最大ファイルサイズを超えるファイルが1つありました。大きなファイルをダウンロードしようとしていて、Debianで「ファイルサイズの制限を超えています」というメッセージが表示されたのを確認できました。

その後、/ etc / security / limits.confファイルを編集して、次の行を追加します：* hard fsize 1000000 * soft fsize 1000000

新しい制限値を実際に「適用」するには、再ログインする必要があります

接線的に関連していて、ルートアクセスがなく、RPM（rpm2cpioを使用）または他のパッケージ（.deb、..）から手動でGitをサブフォルダーに抽出する場合にのみ役立ちます。一般的なユースケース：企業サーバーで古いバージョンよりも新しいバージョンのGitを使用しようとします。

初期のEOFの言及fatal: index-pack failed なしで git cloneが失敗し、代わりにに関するヘルプメッセージが表示されるusage: git index-pack場合は、バージョンの不一致があり、次の--exec-pathパラメーターを使用してgitを実行する必要があります。

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

これを自動的に行うには、次のように指定します~/.bashrc。

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

sshではなくgit（v2.17.1）を使用して、同じエラーログを取得しました。私の場合の解決策は：

1. サーバーのgit bareリポジトリに移動します。
2. を呼び出しgit gcます。

git-gcのドキュメントを参照してください：https : //git-scm.com/docs/git-gc。

例えば：

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc

これで、たとえばクライアント側で、エラーなしでこのリポジトリを複製できます。

git clone git@my_server_url.com:my_repo_name

コマンドgit gcは、同様のgit push問題を回避するためにgitクライアント側で呼び出されるのに役立ちます。

他の（ハック）ソリューションは、履歴のない最後のマスターをダウンロードしています：

git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name

バッファオーバーフローが発生しない可能性があります。

私の場合、プロトコルがhttpsのときは何も機能せず、sshに切り替えて、履歴全体ではなく最後のコミットからリポジトリをプルし、特定のブランチもプルしたことを確認しました。これは私を助けました：

git clone --depth 1 "ssh：.git" --branch "specific_branch"

その間に私が行っていたすべてのダウンロードをオフにしたため、おそらく一部のスペースが解放され、帯域幅がアップ/ダウンした

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にマージします）。

私は同じ問題を抱えています。上記の最初の手順に従ってクローンを作成できましたが、他に何もできません。古いブランチをフェッチ、プル、チェックアウトできません。

各コマンドの実行速度は通常よりも遅く、オブジェクトの圧縮後に終了します。

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の編集があります。この後、どのコマンドも正常に通常の速度で実行できます。

ここでほとんどの答えを試しましたが、PUTTY SSHクライアントでエラーが発生しましたですべての可能な星座で。

OpenSSHに切り替えたら、エラーはなくなりました（環境変数GIT_SSHを削除してgit bashを再起動します）。

私は新しいマシンと最新のgitバージョンを使用していました。他の多くの古いマシン（AWSも同様）では、PUTTYでもgit設定なしでも期待どおりに機能しました。

同じ問題が発生しました。REPOは大きすぎてSSH経由でダウンロードできませんでした。@ elin3tが推奨するように、HTTP / HTTPSを介してクローンを作成し、.git / configのリモートURLを変更してSSH REPOを使用します。

実行すると以下と同じ問題が発生しました 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。コミットされていない変更が多すぎるため、コミットしていないすべての変更をコミットしてプッシュすることで問題を修正しました。

上記の解決策はどれも私にとってうまくいきませんでした。

最終的に私のために働いた解決策は、SSHクライアントを切り替えることでした。GIT_SSH環境変数は、Windows Server 2019によって提供されるOpenSSHに設定されました。バージョン7.7.2.1

C:\Windows\System32\OpenSSH\ssh.exe

私は単にパテを取り付けました、0.72

choco install putty

そしてGIT_SSHを

C:\ProgramData\chocolatey\lib\putty.portable\tools\PLINK.EXE

ここで行った提案はほぼすべて試しましたが、どれもうまくいきませんでした。私たちにとってこの問題は気まぐれで、リポジトリが大きくなるほど（Jenkins Windowsビルドスレーブで）悪化しました。

gitで使用されているsshのバージョンになった。Gitは、core.sshCommand変数を介してユーザーの.gitconfigファイルで指定されたOpen SSHのいくつかのバージョンを使用するように構成されました。その行を削除すると修正されました。これは、Windowsに、デフォルトで使用される、より信頼性の高い、互換性のあるバージョンのSSHが同梱されているためだと思います。

これは私にとってはうまくいきました、標準のネームサーバーが指定されていないためGoogleのネームサーバーを設定し、その後ネットワークを再起動しました：

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

gitクローンから、私は得ていました：

error: inflate: data stream error (unknown compression method)
fatal: serious inflate inconsistency
fatal: index-pack failed

マシンを再起動した後、レポのクローンを作成することができました。

Windowsを使用している場合、「index-pack」が失敗してgit cloneが失敗することを確認する必要がありますか？。

基本的に、git.exe daemon ...コマンドを実行した後、そのコンソールウィンドウからテキストを選択します。プル/クローンを再試行してください。今はうまくいくかもしれません！

詳細については、この回答を参照してください。

ドライブに十分な空き容量があることを確認してください

これらはどれもうまくいきませんでしたが、Herokuの組み込みツールを使用することでうまくいきました。

heroku git:clone -a myapp

ドキュメントはこちら：https : //devcenter.heroku.com/articles/git-clone-heroku-app