ร้ายแรง: ต้น EOF ร้ายแรง: ดัชนีแพ็คล้มเหลว

ฉัน googled และพบวิธีแก้ปัญหามากมาย แต่ก็ไม่ได้ผลสำหรับฉัน

ฉันพยายามโคลนจากเครื่องหนึ่งโดยเชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลซึ่งอยู่ในเครือข่าย LAN
การรันคำสั่งนี้จากเครื่องอื่นทำให้เกิดข้อผิดพลาด
แต่การรันคำสั่ง SAME clone โดยใช้ 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แต่ยังไม่มีความช่วยเหลือ
ใช้ 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

ฉันคิดว่ามีความผิดพลาดกับ msysgit ในรุ่น 1.8.x ที่ทำให้อาการเหล่านี้แย่ลงดังนั้นตัวเลือกอื่นคือลองใช้ git รุ่นก่อนหน้า (<= 1.8.3 ฉันคิดว่า)

ข้อผิดพลาดนี้อาจเกิดขึ้นสำหรับความต้องการหน่วยความจำของคอมไพล์ คุณสามารถเพิ่มบรรทัดเหล่านี้ไปแฟ้มการกำหนดค่าคอมไพล์ทั่วโลกของคุณซึ่งเป็น.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

จากนั้นเพื่อแก้ปัญหาของสาขาในพื้นที่ของคุณเท่านั้น

เปิดไฟล์ config 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 clone --depth 1 --branch $BRANCH $URL

สิ่งนี้จะ จำกัด การเช็คเอาต์ไปยังสาขาที่กล่าวถึงเท่านั้นดังนั้นจะทำให้กระบวนการเร็วขึ้น

หวังว่าจะช่วยได้

ฉันลองคำสั่งทั้งหมดนั้นแล้วก็ไม่มีใครทำงานให้ฉันได้ แต่สิ่งที่ใช้ได้คือเปลี่ยน git_url เป็น http แทน ssh

ถ้าคำสั่ง clone ทำ:

git clone <your_http_or_https_repo_url> 

ถ้าคุณกำลังดึง repo ที่มีอยู่ให้ทำด้วย

git remote set-url origin <your_http_or_https_repo_url>

หวังว่าจะช่วยคนนี้!

ฉันได้รับข้อผิดพลาดนี้เมื่อคอมไพล์มีหน่วยความจำไม่เพียงพอ

การเพิ่มหน่วยความจำบางส่วน (ในกรณีนี้: ปล่อยให้งานคอมไพล์เสร็จสิ้น) แล้วลองอีกครั้งสำหรับฉัน

ในกรณีของฉันมันเป็นปัญหาการเชื่อมต่อ ฉันเชื่อมต่อกับเครือข่าย wifi ภายในซึ่งฉันมีการ จำกัด การเข้าถึงแหล่งข้อมูล นั่นคือการปล่อยให้คอมไพล์ทำการดึงข้อมูลได้ แต่ในบางครั้งมันก็พัง ซึ่งหมายความว่าอาจเป็นปัญหาการเชื่อมต่อเครือข่าย ตรวจสอบว่าทุกอย่างทำงานอย่างถูกต้อง: Antivirus, ไฟร์วอลล์และอื่น ๆ

คำตอบของ elin3t จึงมีความสำคัญเนื่องจาก ssh ปรับปรุงประสิทธิภาพการดาวน์โหลดเพื่อให้สามารถหลีกเลี่ยงปัญหาเครือข่ายได้

การกำหนดค่าด้านล่างนี้ใช้ไม่ได้สำหรับฉัน

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

ในฐานะที่เป็นความคิดเห็นก่อนหน้านี้มันอาจเป็นปัญหาหน่วยความจำจากคอมไพล์ ดังนั้นฉันพยายามลดเธรดการทำงาน (จาก 32 เป็น 8) เพื่อที่จะไม่ได้รับข้อมูลจำนวนมากจากเซิร์ฟเวอร์ในเวลาเดียวกัน จากนั้นฉันก็เพิ่ม "-f" เพื่อบังคับให้ซิงค์โครงการอื่น ๆ

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

จากนั้นก็ใช้งานได้ดีในขณะนี้

repo sync -f -j8

คำตอบก่อนหน้านี้แนะนำให้ตั้งค่าเป็น 512m ฉันว่ามีเหตุผลที่คิดว่ามันต่อต้านในสถาปัตยกรรม 64 บิต เอกสาร core.packedGitLimitพูดว่า:

ค่าเริ่มต้นคือ 256 MiB บนแพลตฟอร์ม 32 บิตและ 32 TiB (ไม่ จำกัด จำนวนอย่างมีประสิทธิภาพ) บนแพลตฟอร์ม 64 บิต สิ่งนี้ควรสมเหตุสมผลสำหรับผู้ใช้ / ระบบปฏิบัติการทั้งหมดยกเว้นในโครงการที่ใหญ่ที่สุด คุณอาจไม่จำเป็นต้องปรับค่านี้

หากคุณต้องการลองตรวจสอบว่าคุณได้ตั้งค่าไว้แล้วลบการตั้งค่า:

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

โปรดทราบว่า Git 2.13.x / 2.14 (ไตรมาสที่ 3 ปี 2560) จะเพิ่มค่าเริ่มต้นcore.packedGitLimitซึ่งมีผลgit fetch:
ค่าขีด จำกัด การบรรจุแบบ git เริ่มต้นได้รับการยกระดับบนแพลตฟอร์มขนาดใหญ่ ( จาก 8 GiB เป็น 32 GiB ) เพื่อบันทึก " git fetch" จากความล้มเหลว ในขณะที่ " gc" กำลังทำงานแบบขนาน

ดูกระทำ be4ca29 (20 เมษายน 2017) โดยเดวิดเทอร์เนอ (csusbdt )
ช่วยโดย: เจฟฟ์คิง (peff )
^{(ผสานโดยJunio ​​C Hamano - gitster- in d97141b , 16 พฤษภาคม 2017)}

เพิ่มขึ้น core.packedGitLimit

เมื่อcore.packedGitLimitเกินแล้วคอมไพล์จะปิดแพ็ค
หากมีการดำเนินการหีบห่อที่เกิดขึ้นควบคู่กับการดึงข้อมูลการดึงข้อมูลอาจเปิดแพ็คและจากนั้นถูกบังคับให้ปิดเนื่องจากการบีบอัด GitLimit ถูกตี
การบรรจุใหม่สามารถลบแพ็คออกจากใต้การดึงข้อมูลทำให้การดึงข้อมูลล้มเหลว

เพิ่มcore.packedGitLimitค่าเริ่มต้นเพื่อป้องกันสิ่งนี้

บนเครื่อง 64 บิต x86_64 ปัจจุบันมีที่อยู่ 48 บิต
ปรากฏว่าเครื่อง ARM 64 บิตไม่มีพื้นที่แอดเดรสมาตรฐาน (นั่นคือมันแตกต่างกันไปตามผู้ผลิต) และเครื่อง 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 แต่ความจริงที่ว่าที่เก็บของฉันมีหนึ่งไฟล์เกินขนาดไฟล์สูงสุดที่อนุญาตในระบบของฉัน ฉันสามารถตรวจสอบได้ว่าพยายามดาวน์โหลดไฟล์ขนาดใหญ่และได้รับ "ขนาดไฟล์เกินขีด จำกัด " บน Debian

หลังจากนั้นฉันแก้ไขไฟล์ /etc/security/limits.conf ของฉันและเพิ่มจุดสิ้นสุดของบรรทัดต่อไปนี้: * hard fsize 1000000 * soft fsize 1000000

หากต้องการ "ใช้งาน" ค่าขีด จำกัด ใหม่คุณจะต้องลงชื่อเข้าใช้อีกครั้ง

มีความเกี่ยวข้องและอาจมีประโยชน์ในกรณีที่คุณไม่มีการเข้าถึงรูทและดึง Git จาก RPM (ด้วย rpm2cpio) หรือแพ็คเกจอื่น ๆ (.deb, .. ) ด้วยตนเองลงในโฟลเดอร์ย่อย กรณีการใช้งานทั่วไป: คุณพยายามใช้ Git รุ่นใหม่กว่ารุ่นเก่าบนเซิร์ฟเวอร์องค์กร

หาก git clone ล้มเหลวfatal: index-pack failed โดยไม่มี EOF ก่อนหน้า แต่พูดถึงข้อความช่วยเหลือเกี่ยวกับusage: git index-packว่ามีเวอร์ชันที่ไม่ตรงกันและคุณต้องรัน git ด้วย--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 (v2.17.1) มากกว่า ssh ในการแก้ปัญหากรณีของฉันคือ:

1. เข้าสู่ที่เก็บ git ของเซิร์ฟเวอร์ของฉัน
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 เพื่อหลีกเลี่ยงgit pushปัญหาที่คล้ายกัน

โซลูชันอื่น ๆ (แฮ็ค) กำลังดาวน์โหลดมาสเตอร์คนสุดท้ายที่ไม่มีประวัติ:

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

มีโอกาสที่บัฟเฟอร์ล้นจะไม่เกิดขึ้น

ในกรณีของฉันไม่มีอะไรทำงานเมื่อโปรโตคอลเป็น https จากนั้นฉันเปลี่ยนเป็น ssh และทำให้แน่ใจว่าฉันดึง repo จากการกระทำครั้งสุดท้ายและไม่ใช่ประวัติศาสตร์ทั้งหมดและสาขาเฉพาะ สิ่งนี้ช่วยฉัน:

git clone - ความลึก 1 "ssh: .git" - สาขา“ 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-Fix ในภายหลังเพื่อดูแล)

ผมมีปัญหาเดียวกัน. ทำตามขั้นตอนแรกข้างต้นฉันสามารถโคลน แต่ฉันไม่สามารถทำอะไรได้อีก ไม่สามารถดึงดึงหรือชำระเงินสาขาเก่า

แต่ละคำสั่งทำงานช้ากว่าปกติมากจากนั้นตายหลังจากบีบอัดวัตถุ

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 Client ที่มีกลุ่มดาวที่เป็นไปได้ทั้งหมด

เมื่อฉันเปลี่ยนไปใช้ OpenSSHข้อผิดพลาดก็หายไป (ลบตัวแปรสภาพแวดล้อม GIT_SSH และรีสตาร์ท git bash)

ฉันใช้เครื่องใหม่และรุ่นคอมไพล์รุ่นใหม่ล่าสุด ในเครื่องอื่น ๆ / รุ่นเก่า (AWS เช่นกัน) มันทำงานได้ตามที่คาดไว้กับ PUTTY และไม่มีการกำหนดค่า git

ฉันพบปัญหาเดียวกัน REPO ใหญ่เกินไปที่จะดาวน์โหลดผ่าน SSH เช่นเดียวกับที่แนะนำ @ elin3t ฉันได้โคลนผ่าน HTTP / HTTPS และเปลี่ยน URL ระยะไกลใน. git / configเพื่อใช้ 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 ถูกตั้งค่าเป็น OpenSSH ที่จัดทำโดย Windows Server 2019 เวอร์ชัน 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

ฉันพยายามทำตามคำแนะนำทั้งหมดที่นี่ แต่ก็ไม่ได้ผล สำหรับเราปัญหาคือเจ้าอารมณ์และแย่ลงเรื่อย ๆ ยิ่ง repos ยิ่งใหญ่ขึ้น (บน Jenkins Windows ของเราสร้างทาส)

ในที่สุดมันก็เป็นเวอร์ชั่นของ ssh ที่ใช้โดย git Git ได้รับการกำหนดค่าให้ใช้ Open SSH บางเวอร์ชันซึ่งระบุในไฟล์ผู้ใช้. gitconfig ผ่านตัวแปร core.sshCommand การลบบรรทัดนั้นจะแก้ไข ฉันเชื่อว่าเป็นเพราะ Windows ตอนนี้มาพร้อมกับ SSH รุ่นที่เชื่อถือได้ / เข้ากันได้มากกว่าซึ่งจะถูกใช้เป็นค่าเริ่มต้น

สิ่งนี้ใช้งานได้สำหรับฉันตั้งค่า Googles เนมเซิร์ฟเวอร์เนื่องจากไม่ได้ระบุเนมเซิร์ฟเวอร์มาตรฐานตามด้วยการรีสตาร์ทเครือข่าย:

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

จากโคลนคอมไพล์ฉันได้รับ:

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

หลังจากรีบูตเครื่องของฉันฉันสามารถโคลน repo ดี

หากคุณใช้ Windows คุณอาจต้องการตรวจสอบการคอมไพล์ git ล้มเหลวโดยที่ "index-pack" ล้มเหลว?.

โดยทั่วไปหลังจากรันgit.exe daemon ...คำสั่งของคุณให้เลือกข้อความบางส่วนจากหน้าต่างคอนโซลนั้น ลองดึง / โคลนอีกครั้งมันอาจใช้งานได้แล้วตอนนี้!

ดูคำตอบนี้สำหรับข้อมูลเพิ่มเติม

ตรวจสอบให้แน่ใจว่าไดรฟ์ของคุณมีเนื้อที่ว่างเพียงพอ

สิ่งเหล่านี้ไม่ได้ผลสำหรับฉัน แต่การใช้เครื่องมือในตัวของ Heroku ก็ใช้เคล็ดลับนี้ได้

heroku git:clone -a myapp

เอกสารที่นี่: https://devcenter.heroku.com/articles/git-clone-heroku-app