fatal: 초기 EOF fatal: 인덱스 팩 실패

fatal: 초기 EOF fatal: 인덱스 팩 실패

저는 구글에서 많은 해결책을 찾았지만 아무 것도 저에게 맞지 않습니다.

LAN 네트워크에 있는 원격 서버에 연결하여 한 시스템에서 복제하려고 합니다.
다른 컴퓨터에서 이 명령을 실행하면 오류가 발생합니다.
그러나 서버에서 git://192.168.8.5...를 사용하여 동일한 복제 명령을 실행하면 문제가 없고 성공적입니다.

무슨 생각 있어요?

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하지만 도움도 안 됩니다.
0Git 버 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의 메모리 요구에 대해 발생할 수 있습니다.파일에 할 수 . 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.
기본 압축 수준을 나타내는 정수 -1..9. -1은 zlib 기본값입니다.
0은 압축이 없음을 의미하며, 1.9는 다양한 속도/크기 트레이드오프이며, 9는 가장 느립니다.
설정된 경우 core.looseCompression 및 pack.compression과 같은 다른 압축 변수에 기본값을 제공합니다.

@ingy가 여기서 말했듯이:

얕은 클론

먼저 압축을 해제합니다.

git config --global core.compression 0

다음으로 부분 복제를 수행하여 아래로 전달되는 정보의 양을 잘라 보겠습니다.

git clone --depth 1 <repo_URI>

그러면 새 디렉터리로 이동하여 복제본의 나머지 부분을 검색합니다.

git fetch --unshallow

또는, 또는,

git fetch --depth=2147483647

자, 당기기를 해보세요.

git pull --all

---

그러면 당신의 지역 지점만 추적하는 마스터의 문제를 해결하기 위해.

파일을 . (git 구을엽니다성일파(다엽니▁(▁open구▁your).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 config --global pack.windowsMemory 256m

저의 경우, 이것은 꽤 도움이 되었습니다.

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

이렇게 하면 체크아웃이 언급된 지점으로만 제한되므로 프로세스 속도가 빨라집니다.

이것이 도움이 되기를 바랍니다.

저는 그 모든 명령을 시도했지만 아무 것도 저에게 효과가 없었지만, 효과가 있는 것은 git_url을 ssh 대신 http로 변경하는 것이었습니다.

if is clone 명령을 수행합니다.

git clone <your_http_or_https_repo_url> 

그렇지 않으면 기존 repo를 풀링하는 경우, 사용합니다.

git remote set-url origin <your_http_or_https_repo_url>

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

저는 macOS Big Sur M1 칩에서 이 문제에 직면했고 어떤 솔루션도 저에게 적합하지 않았습니다.

편집: M2 칩의 솔루션으로도 작동합니다.

저는 아래의 ulimit을 늘려 해결했습니다.

ulimit -f 2097152
ulimit -c 2097152
ulimit -n 2097152

위의 명령을 실행하면 현재 터미널 세션에만 유효하므로 먼저 이 명령을 실행한 다음 리포지토리를 복제하십시오.

Git 메모리가 부족할 때 이 오류가 발생했습니다.

약간의 메모리를 확보하고(이 경우: 컴파일 작업을 완료하도록 허용) 다시 시도하는 것이 저에게 효과적이었습니다.

저의 경우는 연결 문제였습니다.저는 내부 와이파이 네트워크에 연결되어 있었고, 거기서 저는 자원에 대한 접근이 제한되어 있었습니다.그것은 git가 fetch를 하도록 내버려두는 것이었지만 특정 시간에 그것은 충돌했습니다.즉, 네트워크 연결 문제일 수 있습니다.바이러스 백신, 방화벽 등 모든 것이 제대로 실행되고 있는지 확인합니다.

그러므로 elin3t의 대답은 중요합니다. 왜냐하면 ssh는 다운로드의 성능을 향상시켜 네트워크 문제를 피할 수 있기 때문입니다.

아래의 구성을 설정하는 것은 저에게 맞지 않습니다.

[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

저의 경우 프로토콜이 https일 때는 아무 것도 작동하지 않았습니다. 그런 다음 ssh로 전환하고 전체 기록이 아닌 마지막 커밋에서 repo를 꺼냈습니다. 그리고 특정 분기도 마찬가지입니다.이것은 저에게 도움이 되었습니다.

git clone --depth 1 "depth: .git" --depth "specific_details"

2는 Git 2.13.x/2.14(2017년 3분기)를 .core.packedGitLimit어떤 것이 영향을 주는지git fetch:
기본 packed-git 제한 값은 "을(를) 절약하기 위해 더 큰 플랫폼(8Gb에서 32Gb로)에서 올렸습니다.git fetch으)ㄹ 수 있는" 동안의 (로부터.gc병렬로 실행 중입니다.

David csusbdtTurner()의 commit be4ca29(2017년 4월 20일)를 참조하십시오.
도움을 받은 사람: 제프 peff킹().
^{(주니오 C 하마노에 의해 합병 -- -- d97141b, 2017년 5월 16일 커밋)}

▁increase가 늘립니다.core.packedGitLimit

때core.packedGitLimit초과하면 git이 팩을 닫습니다.
fetch와 병행하여 진행 중인 repack 작업이 있는 경우 fetch가 팩을 연 다음 packedGitLimit이 적중되어 강제로 닫을 수 있습니다.
그런 다음 재패키지가 가져오기 아래에서 팩 아웃을 삭제하여 가져오기가 실패할 수 있습니다.

▁increase가 늘립니다.core.packedGitLimit이를 방지하기 위한 의 기본값입니다.

현재 64비트 x86_64 시스템에서는 48비트의 주소 공간을 사용할 수 있습니다.
64비트 ARM 시스템에는 표준 주소 공간이 없으며(제조업체에 따라 다름) IA64 및 POWER 시스템에는 전체 64비트가 있습니다.
따라서 48비트가 우리가 합리적으로 신경 쓸 수 있는 유일한 한계입니다.커널 사용을 위해 48비트 주소 공간의 몇 비트를 예약하고 나머지 45비트까지 사용합니다(엄격히 필요한 것은 아니지만 안전한 것이 좋습니다.
이 크기에 가까운 곳에 곧 기가비트 저장소가 없을 것이므로 오류를 방지할 수 있습니다.

저도 같은 문제가 있어요.위의 첫 번째 단계에 따라 복제할 수 있었지만 다른 작업은 수행할 수 없습니다.오래된 분기를 가져오거나 끌거나 체크아웃할 수 없습니다.

각 명령은 평소보다 훨씬 느리게 실행되고 개체를 압축한 후에 사라집니다.

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개의 편집 내용이 포함됩니다.이 후에는 일반 속도로 모든 명령을 정상적으로 수행할 수 있습니다.

저도 같은 문제가 있었습니다. 심지어 웹사이트에서 직접 zip 파일로 프로젝트를 다운로드하려고 했지만 다운로드가 정확히 같은 비율로 중단되었습니다.

이 한 줄이 나의 문제를 부적처럼 고쳤습니다.

git config --global core.compression 0

다른 답변에서 이 문제를 언급한 것으로 알고 있지만, 여기에 있는 아무도 이 라인만으로 문제를 해결할 수 있다고 언급하지 않았습니다.

도움이 되길 바랍니다.

Git 로그는 다음과 같은 연결 또는 SSH 인증 오류를 제안할 수 있기 때문에 혼란스럽습니다.ssh_dispatch_run_fatal: Connection to x.x.x.x port yy: message authentication code incorrect,the remote end hung up unexpectedly,early EOF.

서버측 솔루션

서버 측에서 Git 저장소를 최적화합니다.

1. 내 서버의 Git Bare 저장소에 들어갑니다.
2. 부르세요.
3. 콜

예:

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 repack -A

이제 클라이언트 측에서 오류 없이 이 저장소를 복제할 수 있습니다.

git clone git@my_server_url.com:my_repo_name

git gc유사성을 피하기 위해 git 클라이언트 측에서 호출될 수 있습니다.git push문제.

---

Gitlab 서비스의 관리자인 경우 - 수동으로 하우스키핑을 트리거합니다.내부적으로 호출됩니다.git gc또는git repack.

---

고객측 솔루션

다른(해킹, 클라이언트 측만 해당) 솔루션은 기록이 없는 마지막 마스터를 다운로드하는 것입니다.

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

버퍼 오버플로가 발생하지 않을 가능성이 있습니다.

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

에 저는 제 에▁my다를 편집했습니다./etc/security/limits.conf파일 끝에 다음 행을 추가합니다.

• 하드 fsize 1000000
• 소프트 fsize 1000000

새 제한 값을 실제로 "적용"하려면 다시 로그인해야 합니다.

git buffer를 설정한 후 여러 번 시도해 보았는데, 질문에서 언급했듯이 지금은 작동하는 것 같습니다.

따라서 이 오류가 발생한 경우 다음 명령을 실행합니다.

git config --global http.postBuffer 2M

그리고 나서 몇 시간 동안 다시 시도합니다.

참조:

git 푸시 오류: RPC 실패, 결과=56, HTTP 코드 = 0

네트워크 품질이 중요합니다. 다른 네트워크로 전환해 보십시오.제가 인터넷 연결을 Virgin Media의 고속 지상 기반 광대역에서 휴대폰의 핫스팟으로 변경하는 것이 도움이 되었습니다.

그 전에 클론 크기를 제한하기 위해 허용된 답변을 시도했고, 64비트 버전과 32비트 버전 사이에서 전환을 시도했으며, Git 파일 캐시를 비활성화하려고 시도했지만 아무도 도움이 되지 않았습니다.

그런 다음 모바일을 통해 연결로 전환하고 첫 번째 단계(git clone --depth 1 <repo_URI >)에 성공했습니다.광대역으로 다시 전환했지만 다음 단계(git fetch --unshlow)도 실패했습니다.그래서 저는 지금까지 복제된 코드를 삭제하고 모바일 네트워크로 전환하여 기본 방법으로 다시 시도했습니다(git clone <repo_URI >)을 사용하여 문제 없이 성공했습니다.

압축을 git config --global core.compression 9로 변경했을 때 작동했습니다.

작동합니다.

여기서 거의 모든 답을 시도했지만 운이 없었습니다.마침내 Github 데스크톱 앱인 https://desktop.github.com/ 을 사용하여 작동했습니다.

M1 칩이 있는 맥북/몬트리는 그것이 중요한지 확실하지 않습니다.

여기서 대부분의 답변을 시도해보니 가능한 모든 별자리가 포함된 PUTTY SSH Client에 오류가 발생했습니다.

OpenSSH로 전환하면 오류가 사라집니다(환경 변수 GIT_SSH를 제거하고 Gitbash를 다시 시작합니다).

저는 새로운 기계와 최신 Git 버전을 사용하고 있었습니다.많은 다른/구형 컴퓨터(AWS도 마찬가지)에서도 GIT 구성 없이 PUTTY에서 예상대로 작동했습니다.

위의 어떤 해결책도 저에게 효과가 없었습니다.

결국 제게 맞는 해결책은 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

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

다음 사이트에서 진행됩니다. https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

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

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

접선적으로 관련되어 있으며 루트 액세스 권한이 없고 RPM(rpm2cpio 포함) 또는 다른 패키지(.deb, ...)에서 Git를 하위 폴더로 수동으로 추출하는 경우에만 유용합니다.일반적인 사용 사례: 회사 서버에서 오래된 버전의 Git보다 새로운 버전의 Git를 사용하려고 합니다.

에서 Git 하는 경우 Git 론이패는경우fatal: index-pack failed 초기 EOF 언급 없이 대신 다음에 대한 도움말 메시지usage: git index-pack와 함께 .--exec-path매개변수:

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

자동으로 의 이작업자지에정다합다니음을서하려.~/.bashrc:

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

Git Clone을 통해 다음을 얻었습니다.

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

컴퓨터를 재부팅한 후 다시 복제할 수 있었습니다.

그 동안 수행하던 다운로드를 모두 해제하여 공간을 확보하고 대역폭을 삭제했습니다.

git-daemon 문제는 v2.17.0(작동하지 않는 v2.16.2.1로 확인됨)에서 해결된 것 같습니다. 즉, 콘솔에서 "출력 버퍼 잠금"을 위해 텍스트를 선택하는 해결 방법은 더 이상 필요하지 않습니다.

https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt 에서:

• "깃 데몬"에 대한 다양한 수정.(15e58efejk/http-message는 나중에 유지 관리에 추가됨).

저도 같은 문제를 경험했습니다.REPO가 너무 커서 SSH를 통해 다운로드할 수 없습니다. @elin3t의 권장 사항처럼 HTTP/HTTPS를 통해 복제한 후 SSH REPO를 사용하도록 .git/config의 REMOTE URL을 변경했습니다.

언급URL : https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed