web-dev-qa-db-ja.com

致命的:早い EOF fatal:index-packが失敗しました

私はグーグルで多くの解決策を見つけましたが、どれも私のために働きません。

LANネットワークにあるリモートサーバーに接続して、1台のマシンからクローンを作成しようとしています。
他のマシンからこのコマンドを実行するとエラーが発生します。
しかし、git://192.168.8.5 ...を使用してSAME cloneコマンドを実行しても問題ありません。

何か案は ?

[email protected] ~
$ 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
215
William

まず、圧縮を無効にします。

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、私は思う)。

414
ingyhere

このエラーはgitのメモリニーズに対して発生するかもしれません。この問題を解決するために、.gitconfig$USER_HOMEであるグローバルgit設定ファイルにこれらの行を追加することができます。

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

ついに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などの他の圧縮変数にデフォルト値を提供します。

11
Jacky

@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はリモートブランチをすべて引っ張ります。

7
cmpickle

私の場合、これはとても役に立ちました。

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

これはチェックアウトを言及されたブランチだけに制限するでしょう、そしてそれ故にプロセスをスピードアップするでしょう。

これが役立つことを願っています。

5
sMajeed

Gitがメモリを使い果たしたとき、私はこのエラーを得ました。

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

5
André Laszlo

私はすべてのコマンドを試してみましたが、私にはうまくいきませんが、うまくいったのはgit_urlを代わりにhttpに変更することでしたssh

クローンコマンドがあれば:

git clone <your_http_or_https_repo_url> 

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

git remote set-url Origin <your_http_or_https_repo_url>

これが誰かに役立つことを願っています!

4
elin3t

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

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

4
iberbeu

以前の回答では、512mに設定することを推奨しています。 64ビットアーキテクチャでは逆効果だと考える理由があると思います。 core.packedGitLimitのドキュメント は次のとおりです。

デフォルトは、32ビットプラットフォームでは256 MiB、64ビットプラットフォームでは32 TiB(事実上無制限)です。これは、最大のプロジェクトを除き、すべてのユーザー/オペレーティングシステムにとって妥当なものでなければなりません。おそらく、この値を調整する必要はありません。

試してみたい場合は、設定しているかどうかを確認してから、設定を削除してください。

git config --show-Origin core.packedGitLimit
git config --unset --global core.packedGitLimit
1
8DH

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 d97141bJ浜野順夫-gitster- に合併)

core.packedGitLimitを増やす

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

これを防ぐには、core.packedGitLimitのデフォルト値を増やします。

現在の64ビットx86_64マシンでは、48ビットのアドレス空間が利用可能です。
64ビットARMマシンには標準のアドレススペースがない(つまり、メーカーによって異なる)ようであり、IA64およびPOWERマシンにはフル64ビットがあります。
したがって、合理的に注意できるのは48ビットのみです。カーネルの使用のために48ビットのアドレス空間のいくつかのビットを予約し(これは厳密には必要ではありませんが、安全である方が良いです)、残りの45まで使用します。
Gitリポジトリはすぐにこの大規模な場所の近くに配置されることはないため、これにより障害を防ぐことができます。

1
VonC

ここで答えのほとんどを試してみました、私は PuTTY SSHクライアント すべての可能な星座でエラーを得ました。

OpenSSHに切り替えたら エラーが消えました(環境変数GIT_SSHを削除し、git bashを再起動してください)。

私は新しいマシンと最新のgitバージョンを使っていました。他の多くの古いマシン(AWSも同様)では、PuTTYでもgit設定なしで期待通りに動作しました。

0
Max

私は同じ問題を抱えています。上記の最初のステップに従って、私はクローンを作ることができました、しかし、私は他に何もすることができません。古いブランチを取得、取得、またはチェックアウトできません。

各コマンドは通常よりもずっと遅く実行され、その後オブジェクトを圧縮した後に終了します。

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回の編集が履歴に含まれています。この後は、通常の速度で任意のコマンドを実行できます。

0
Vishav Premlall

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

0
Rodel

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

私の場合は、プロトコルがhttpsのときには何もうまくいきませんでした。それから私はsshに切り替えて、確実に履歴全体ではなく、特定のブランチからリポジトリを取り出しました。これは私を助けました:

git clone --depth 1 "ssh:.git" --branch“ specific_branch”

0
Shripada

その間に行っていたすべてのダウンロードをオフにしたため、スペースが多少解放され、帯域幅が上下した

0

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

0

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を確認しました。非常に多くのコミットされていない変更があったため、コミットおよびプッシュすべてのコミットされていない変更によって問題を修正しました。

0
Kiran Reddy