gây tử vong: EOF sớm gây tử vong: chỉ số gói không thành công

Tôi đã googled và tìm thấy nhiều giải pháp nhưng không có giải pháp nào cho tôi.

Tôi đang cố gắng sao chép từ một máy bằng cách kết nối với máy chủ từ xa trong mạng LAN.
Chạy lệnh này từ một máy khác gây ra lỗi.
Nhưng chạy lệnh SAME clone bằng git: //192.168.8.5 ... tại máy chủ thì không sao và thành công.

Có ý kiến ​​gì không?

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

Tôi đã thêm cấu hình này trong .gitconfignhưng không có giúp đỡ.
Sử dụng phiên bản git 1.8.5.2.msysgit.0

[core]
    compression = -1

Đầu tiên, tắt nén:

git config --global core.compression 0

Tiếp theo, hãy thực hiện một bản sao một phần để cắt bớt lượng thông tin đi xuống:

git clone --depth 1 <repo_URI>

Khi nó hoạt động, đi vào thư mục mới và lấy phần còn lại của bản sao:

git fetch --unshallow 

hoặc, luân phiên,

git fetch --depth=2147483647

Bây giờ, làm một kéo thường xuyên:

git pull --all

Tôi nghĩ rằng có một trục trặc với msysgit trong các phiên bản 1.8.x làm trầm trọng thêm các triệu chứng này, vì vậy, một lựa chọn khác là thử với phiên bản git trước đó (<= 1.8.3, tôi nghĩ vậy).

Lỗi này có thể xảy ra cho nhu cầu bộ nhớ của git. Bạn có thể thêm những dòng sau vào tệp cấu hình git toàn cầu của bạn, đó là .gitconfigtrong $USER_HOME, để khắc phục vấn đề đó.

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

cuối cùng đã được giải quyết bằng git config --global core.compression 9

Từ chuỗi vấn đề BitBucket:

Tôi đã thử gần năm lần, và nó vẫn xảy ra.

Sau đó, tôi đã cố gắng sử dụng nén tốt hơn và nó đã làm việc!

git config --global core.compression 9

Từ Tài liệu Git:

core.compression
Một số nguyên -1..9, biểu thị mức nén mặc định. -1 là mặc định zlib.
0 có nghĩa là không nén và 1..9 là các sự cân bằng tốc độ / kích thước khác nhau, 9 là chậm nhất.
Nếu được đặt, điều này cung cấp mặc định cho các biến nén khác, chẳng hạn như core.looseCompression và pack.compression.

Như @ingyhere đã nói:

Bản sao nông

Đầu tiên, tắt nén:

git config --global core.compression 0

Tiếp theo, hãy thực hiện một bản sao một phần để cắt bớt lượng thông tin đi xuống:

git clone --depth 1 <repo_URI>

Khi nó hoạt động, đi vào thư mục mới và lấy phần còn lại của bản sao:

git fetch --unshallow

hoặc, luân phiên,

git fetch --depth=2147483647

Bây giờ, hãy thực hiện:

git pull --all

Sau đó, để giải quyết vấn đề của chi nhánh địa phương của bạn chỉ theo dõi chủ

mở tệp cấu hình git ( .git/config) của bạn trong trình chỉnh sửa bạn chọn

nơi nó nói:

[remote "origin"]
    url=<git repo url>
    fetch = +refs/heads/master:refs/remotes/origin/master

thay đổi dòng

fetch = +refs/heads/master:refs/remotes/origin/master

đến

fetch = +refs/heads/*:refs/remotes/origin/*

Thực hiện một git fetch và git sẽ kéo tất cả các nhánh từ xa của bạn bây giờ

Trong trường hợp của tôi, điều này khá hữu ích:

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

Điều này sẽ giới hạn thanh toán chỉ cho chi nhánh được đề cập, do đó sẽ tăng tốc quá trình.

Hy vọng điều này sẽ giúp.

Tôi đã thử tất cả các lệnh đó và không có lệnh nào phù hợp với tôi, nhưng những gì hoạt động là thay đổi git_url thành http thay vì ssh

nếu lệnh clone làm:

git clone <your_http_or_https_repo_url> 

khác nếu bạn đang kéo vào repo hiện có, hãy làm điều đó với

git remote set-url origin <your_http_or_https_repo_url>

Hy vọng điều này sẽ giúp ai đó!

Tôi đã gặp lỗi này khi git hết bộ nhớ.

Giải phóng một số bộ nhớ (trong trường hợp này: để cho một công việc biên dịch kết thúc) và thử lại làm việc cho tôi.

Trong trường hợp của tôi đó là một vấn đề kết nối. Tôi đã được kết nối với một mạng wifi nội bộ, trong đó tôi có quyền truy cập hạn chế vào các nguồn tài nguyên. Điều đó đã cho phép git thực hiện việc tìm nạp nhưng tại một thời điểm nhất định, nó đã bị hỏng. Điều này có nghĩa là nó có thể là một vấn đề kết nối mạng. Kiểm tra xem mọi thứ có chạy đúng không: Antivirus, Tường lửa, v.v.

Do đó, câu trả lời của elin3t rất quan trọng vì ssh cải thiện hiệu suất tải xuống để có thể tránh được các sự cố mạng

Cài đặt bên dưới cấu hình không hoạt động đối với tôi.

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

Như bình luận trước, nó có thể là vấn đề bộ nhớ từ git. Vì vậy, tôi cố gắng giảm các chủ đề làm việc (từ 32 xuống 8). Vì vậy, nó sẽ không nhận được nhiều dữ liệu từ máy chủ cùng một lúc. Sau đó, tôi cũng thêm "-f" để buộc đồng bộ hóa các dự án khác.

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

Sau đó, nó hoạt động tốt bây giờ.

repo sync -f -j8

Một câu trả lời trước đó đề nghị cài đặt thành 512m. Tôi muốn nói có nhiều lý do để cho rằng điều đó phản tác dụng trên kiến ​​trúc 64 bit. Các tài liệu cho core.packedGitLimit nói:

Mặc định là 256 MiB trên nền tảng 32 bit và 32 TiB (không giới hạn hiệu quả) trên nền tảng 64 bit. Điều này phải hợp lý cho tất cả người dùng / hệ điều hành, ngoại trừ trên các dự án lớn nhất. Bạn có thể không cần điều chỉnh giá trị này.

Nếu bạn muốn dùng thử, hãy kiểm tra xem bạn đã cài đặt chưa và sau đó xóa cài đặt:

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

Lưu ý rằng Git 2.13.x / 2.14 (quý 3 năm 2017) sẽ tăng mặc định core.packedGitLimitảnh hưởng git fetch:
Giá trị giới hạn git mặc định đã được nâng lên trên các nền tảng lớn hơn ( từ 8 GiB đến 32 GiB ) để lưu " git fetch" từ lỗi (có thể phục hồi) trong khi " gc" đang chạy song song.

Xem cam kết be4ca29 (20 tháng 4 năm 2017) của David Turner ( csusbdt) .
Giúp đỡ: Jeff King ( peff) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết d97141b , ngày 16 tháng 5 năm 2017)}

Tăng core.packedGitLimit

Khi core.packedGitLimitvượt quá, git sẽ đóng gói.
Nếu có một hoạt động đóng gói lại diễn ra song song với tìm nạp, thì quá trình tìm nạp có thể mở một gói và sau đó buộc phải đóng nó do packGitLimit bị tấn công.
Việc đóng gói lại sau đó có thể xóa gói ra từ bên dưới tìm nạp, khiến việc tìm nạp không thành công.

Tăng core.packedGitLimitgiá trị mặc định để ngăn chặn điều này.

Trên các máy x86_64 64 bit hiện tại, có sẵn 48 bit không gian địa chỉ.
Dường như các máy ARM 64 bit không có không gian địa chỉ tiêu chuẩn (nghĩa là nó thay đổi tùy theo nhà sản xuất) và các máy IA64 và POWER có đầy đủ 64 bit.
Vì vậy, 48 bit là giới hạn duy nhất mà chúng ta có thể quan tâm một cách hợp lý. Chúng tôi dành một vài bit của không gian địa chỉ 48 bit cho việc sử dụng kernel (điều này không thực sự cần thiết, nhưng tốt hơn là an toàn) và sử dụng tối đa 45.
Không có kho git nào ở bất cứ đâu gần như thế này bất cứ lúc nào sớm, vì vậy điều này sẽ ngăn chặn sự thất bại.

Sử dụng câu trả lời @cmpickle, tôi đã xây dựng một tập lệnh để đơn giản hóa quá trình nhân bản.

Nó được lưu trữ ở đây: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

Bạn có thể chạy nó bằng cách sử dụng dòng sau:

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

Trong trường hợp của tôi, vấn đề không phải là tham số cấu hình git mà thực tế là kho lưu trữ của tôi có một tệp vượt quá kích thước tệp tối đa được phép trên hệ thống của tôi. Tôi đã có thể kiểm tra nó khi cố tải xuống một tệp lớn và nhận được "Vượt quá giới hạn kích thước tệp" trên Debian.

Sau đó, tôi đã chỉnh sửa tệp /etc/security/limits.conf thêm et vào cuối dòng sau: * hard fsize 1000000 * soft fsize 1000000

Để thực sự "áp dụng" các giá trị giới hạn mới, bạn cần đăng nhập lại

Liên quan liên tục và chỉ hữu ích trong trường hợp bạn không có quyền truy cập root và trích xuất thủ công Git từ RPM (với rpm2cpio) hoặc gói khác (.deb, ..) vào thư mục con. Trường hợp sử dụng điển hình: bạn cố gắng sử dụng phiên bản Git mới hơn phiên bản lỗi thời trên máy chủ của công ty.

Nếu git clone thất bại fatal: index-pack failed mà không đề cập đến EOF sớm mà thay vào đó là thông báo trợ giúp usage: git index-pack, có một phiên bản không khớp và bạn cần chạy git với --exec-paththam số:

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

Để điều này tự động xảy ra, hãy xác định trong ~/.bashrc:

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

Tôi đã có cùng một bản ghi lỗi, sử dụng git (v2.17.1) trên ssh. Trong trường hợp của tôi, giải pháp là:

1. Nhập vào kho lưu trữ git trần của máy chủ của tôi.
2. Gọi git gc.

Xem tài liệu git-gc: https://git-scm.com/docs/git-gc .

Ví dụ:

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

Bây giờ tôi có thể sao chép kho lưu trữ này mà không có lỗi, ví dụ ở phía máy khách:

git clone git@my_server_url.com:my_repo_name

Lệnh git gccó thể giúp gọi ở phía máy khách git để tránh git pushvấn đề tương tự .

Giải pháp (hack) khác đang tải xuống bản gốc cuối cùng mà không có lịch sử:

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

Có khả năng tràn bộ đệm sẽ không xảy ra.

Trong trường hợp của tôi, không có gì hoạt động khi giao thức là https, sau đó tôi chuyển sang ssh và đảm bảo, tôi đã rút repo từ lần xác nhận cuối cùng và không phải toàn bộ lịch sử, và cả chi nhánh cụ thể. Điều này đã giúp tôi:

git clone - ngày 1 "ssh: .git" --branch

Tôi đã tắt tất cả các tải xuống mà tôi đang thực hiện trong thời gian đó, điều này có thể giải phóng một số không gian có thể và xóa băng thông lên / xuống

Vấn đề git-daemon dường như đã được giải quyết trong v2.17.0 (được xác minh với phiên bản v2.16.2.1 không hoạt động). Nghĩa là cách chọn văn bản trong bảng điều khiển để "khóa bộ đệm đầu ra" không còn cần thiết nữa.

Từ https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt :

• Các loại sửa chữa cho "git daemon". (hợp nhất ed15e58efe jk / daemon-fix sau để duy trì).

Tôi có cùng một vấn đề. Theo bước đầu tiên ở trên tôi đã có thể nhân bản, nhưng tôi không thể làm gì khác. Không thể tìm nạp, kéo hoặc kiểm tra các nhánh cũ.

Mỗi lệnh chạy chậm hơn nhiều so với bình thường, sau đó chết sau khi nén các đối tượng.

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

Điều này cũng xảy ra khi ref của bạn đang sử dụng quá nhiều bộ nhớ. Cắt tỉa bộ nhớ cố định này cho tôi. Chỉ cần thêm một giới hạn cho những gì bạn tìm nạp như vậy ->

git fetch --depth=100

Điều này sẽ tìm nạp các tệp nhưng với 100 lần chỉnh sửa cuối cùng trong lịch sử của chúng. Sau này, bạn có thể thực hiện bất kỳ lệnh nào tốt và ở tốc độ bình thường.

Đã thử hầu hết các câu trả lời ở đây, tôi đã gặp lỗi với PUTTY SSH Client với tất cả các chòm sao có thể.

Khi tôi chuyển sang OpenSSH , lỗi đã biến mất (xóa GIT_SSH biến môi trường và khởi động lại git bash).

Tôi đã sử dụng một máy mới và các phiên bản git mới nhất. Trên nhiều máy khác / cũ hơn (AWS cũng vậy), nó đã hoạt động như mong đợi với PUTTY mà không cần bất kỳ cấu hình git nào.

Tôi đã trải qua vấn đề tương tự. REPO quá lớn để có thể tải xuống qua SSH. Giống như @ elin3t được đề xuất, tôi đã nhân bản qua HTTP / HTTPS và thay đổi URL XÓA trong .git / config để sử dụng SSH REPO.

Tôi gặp vấn đề tương tự như dưới đây khi tôi chạy 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

Sau đó, tôi đã kiểm tra git status, Có rất nhiều thay đổi không được cam kết Tôi đã khắc phục vấn đề bằng cách cam kết và đẩy tất cả các thay đổi không được cam kết.

Không có giải pháp nào ở trên làm việc cho tôi.

Giải pháp cuối cùng có hiệu quả với tôi là chuyển đổi máy khách SSH. Biến môi trường GIT_SSH được đặt thành OpenSSH do Windows Server 2019 cung cấp. Phiên bản 7.7.2.1

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

Tôi chỉ cần cài đặt putty, 0,72

choco install putty

Và đã thay đổi GIT_SSH thành

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

Tôi đã thử khá nhiều tất cả các đề xuất được thực hiện ở đây nhưng không có gợi ý nào. Đối với chúng tôi, vấn đề là nóng nảy và trở nên tồi tệ và tồi tệ hơn khi các repos trở nên lớn hơn (trên nô lệ xây dựng Windows Jenkins của chúng tôi).

Nó cuối cùng là phiên bản của ssh đang được sử dụng bởi git. Git đã được cấu hình để sử dụng một số phiên bản Open SSH, được chỉ định trong tệp .gitconfig của người dùng thông qua biến core.sshCommand. Loại bỏ dòng đó đã sửa nó. Tôi tin rằng điều này là do Windows hiện có một phiên bản SSH tương thích / đáng tin cậy hơn được sử dụng theo mặc định.

Điều này làm việc cho tôi, thiết lập máy chủ tên Googles vì ​​không có máy chủ tên tiêu chuẩn nào được chỉ định, tiếp theo là khởi động lại mạng:

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

Từ một bản sao git, tôi đã nhận được:

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

Sau khi khởi động lại máy, tôi đã có thể sao chép repo tốt.

Nếu bạn đang dùng Windows, bạn có thể muốn kiểm tra git clone không thành công với "gói chỉ mục" không? .

Về cơ bản, sau khi chạy git.exe daemon ...lệnh của bạn , chọn một số văn bản từ cửa sổ giao diện điều khiển đó. Thử lại kéo / nhân bản, nó có thể chỉ hoạt động ngay bây giờ!

Xem câu trả lời này để biết thêm.

Đảm bảo ổ đĩa của bạn còn đủ dung lượng

Không ai trong số này làm việc cho tôi, nhưng sử dụng công cụ tích hợp của Heroku đã làm nên chuyện.

heroku git:clone -a myapp

Tài liệu ở đây: https://devcenter.heroku.com/articles/git-clone-heroku-app