치명적 : 초기 EOF 치명적 : 인덱스 팩 실패

나는 googled하고 많은 솔루션을 찾았지만 나에게 도움이되지 않습니다.

LAN 네트워크에있는 원격 서버에 연결하여 한 시스템에서 복제하려고합니다.
다른 머신에서이 명령을 실행하면 오류가 발생합니다.
그러나 서버에서 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했지만 도움 이 되지 않았습니다.
자식 버전 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그 문제를 해결하기 위해.

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

마침내 해결 git config --global core.compression 9

BitBucket 이슈 스레드에서 :

나는 거의 다섯 번 시도했지만 여전히 발생합니다.

그런 다음 더 나은 압축을 사용하려고 시도했습니다.

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을 http 대신 ssh로 변경하는 것이 효과적이었습니다.

복제 명령 인 경우 :

git clone <your_http_or_https_repo_url> 

그렇지 않으면 기존 리포지토리를 사용하는 경우

git remote set-url origin <your_http_or_https_repo_url>

이것이 누군가를 돕기를 바랍니다!

git에 메모리가 부족하면이 오류가 발생했습니다.

약간의 메모리를 확보 (이 경우 컴파일 작업 완료)하고 다시 시도하면 나를 위해 일했습니다.

제 경우에는 연결 문제였습니다. 내부 Wi-Fi 네트워크에 연결되어 리소스에 대한 액세스가 제한되었습니다. 그것은 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 비트 플랫폼에서는 기본값이 256MiB이고 64 비트 플랫폼에서는 32TiB (실제로 무제한)입니다. 가장 큰 프로젝트를 제외하고 모든 사용자 / 운영 체제에 적합해야합니다. 이 값을 조정할 필요는 없습니다.

시도해보고 싶다면 설정되어 있는지 확인한 다음 설정을 제거하십시오.

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit

참고 힘내 2.13.x / 2.14 (Q3 2017) 기본 제기하고 있다고 core.packedGitLimit영향 git fetch:
기본값은 포장 - 자식 한계 값 (더 큰 플랫폼에서 제기 된 8 지브 32 지브에 ) "저장 git fetchA (복구) 실패를" " gc"가 동시에 실행 중입니다.

David Turner ( )의 commit be4ca29 (2017 년 4 월 20 일)를 참조하십시오 . 도움 : Jeff King ( ) . ^{(가 합병 Junio C 하마노 - - 에 d97141b을 투입 , 2017 (16) 월)}csusbdt
peff
gitster

증가하다 core.packedGitLimit

때 core.packedGitLimit초과, 자식은 팩을 닫습니다.
페치와 병렬로 재 포장 작업이 진행되면 페치에서 팩을 연 다음 packGitLimit에 도달하여 팩을 강제로 닫을 수 있습니다.
리팩은 페치 아래에서 팩을 삭제하여 페치에 실패 할 수 있습니다.

core.packedGitLimit이를 방지하려면의 기본값을 늘리십시오 .

현재 64 비트 x86_64 시스템에서는 48 비트의 주소 공간을 사용할 수 있습니다.
64 비트 ARM 시스템에는 표준 크기의 주소 공간이 없으며 (즉, 제조업체에 따라 다름) IA64 및 POWER 시스템에는 전체 64 비트가 있습니다.
따라서 48 비트는 우리가 합리적으로 신경 쓸 수있는 유일한 한계입니다. 우리는 (이 반드시 필요한 것은 아니지만, 안전을 위해 더 낫다) 커널의 사용을위한 48 비트 주소 공간의 몇 비트를 보유하고 나머지 45까지 사용할
언제든지이 큰 근처 어디있을 것 없음 자식 저장소 곧 실패를 방지해야합니다.

@ cmpickle 답변을 사용하여 복제 프로세스를 단순화하는 스크립트를 작성했습니다.

여기에서 호스팅됩니다 : https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

다음 줄을 사용하여 실행할 수 있습니다.

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

필자의 경우 문제는 git 구성 매개 변수가 아니지만 내 저장소에 시스템에서 허용되는 최대 파일 크기를 초과하는 파일이 하나 있다는 사실입니다. 큰 파일을 다운로드하려고하고 데비안에서 "파일 크기 제한 초과"가 표시되는지 확인할 수있었습니다.

그 후 /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. 내 서버의 자식 저장소에 입력하십시오.
2. 전화하십시오 git gc.

자식-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 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 daemon"에 대한 여러 수정 사항. (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 버전을 사용하고있었습니다. 다른 많은 / 이전 컴퓨터 (AWS도)에서는 git 구성없이 PUTTY에서도 예상대로 작동했습니다.

같은 문제가 발생했습니다. REPO가 너무 커서 SSH를 통해 다운로드 할 수 없습니다. @ elin3t 권장과 마찬가지로 HTTP / HTTPS를 통해 복제 하고 SSH REPO를 사용하도록 .git / config 에서 REMOTE URL을 변경했습니다 .

달리면 아래와 같은 문제가 있습니다. 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 clone에서 다음을 얻었습니다.

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

내 컴퓨터를 재부팅 한 후 repo fine을 복제 할 수있었습니다.

Windows를 사용하는 경우 "index-pack"이 실패하여 git clone이 실패했는지 확인하고 싶 습니까? .

기본적으로 git.exe daemon ...명령 을 실행 한 후 해당 콘솔 창에서 일부 텍스트를 선택하십시오. 당기기 / 복제를 다시 시도하십시오. 지금 작동 할 수도 있습니다!

자세한 내용은 이 답변 을 참조하십시오.

드라이브에 충분한 공간이 있는지 확인하십시오

이것들 중 어느 것도 나를 위해 일하지는 않았지만 Heroku의 내장 도구를 사용하여 트릭을 만들었습니다.

heroku git:clone -a myapp

여기에 설명서 : https://devcenter.heroku.com/articles/git-clone-heroku-app