ปลายทางระยะไกลวางสายโดยไม่คาดคิดในขณะที่คอมไพล์โคลน

gitไคลเอนต์ของฉันล้มเหลวซ้ำ ๆ กับข้อผิดพลาดต่อไปนี้หลังจากพยายามโคลนที่เก็บบางครั้ง

สิ่งที่อาจเป็นปัญหาที่นี่?

หมายเหตุ:ฉันได้ลงทะเบียนคีย์ SSH ของฉันกับผู้ให้บริการโฮสต์ GIT แล้ว

Receiving objects:  13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly

วิธีแก้ปัญหาอย่างรวดเร็ว:

ด้วยข้อผิดพลาดแบบนี้ฉันมักจะเริ่มต้นด้วยการเพิ่มpostBufferขนาดโดย:

git config --global http.postBuffer 524288000

(ความคิดเห็นบางส่วนด้านล่างรายงานต้องเพิ่มค่าเป็นสองเท่า):

git config --global http.postBuffer 1048576000

ข้อมูลมากกว่านี้:

จากgit configหน้าคน , http.postBufferเป็นเรื่องเกี่ยวกับ:

ขนาดสูงสุดในหน่วยไบต์ของบัฟเฟอร์ที่ใช้โดยการส่ง HTTP อัจฉริยะเมื่อ POSTing ข้อมูลไปยังระบบระยะไกล
สำหรับคำร้องขอที่ใหญ่กว่าขนาดบัฟเฟอร์นี้ HTTP / 1.1 และTransfer-Encoding: chunkedใช้เพื่อหลีกเลี่ยงการสร้างไฟล์แพ็คขนาดใหญ่ในเครื่อง ค่าเริ่มต้นคือ 1 MiB ซึ่งเพียงพอสำหรับคำขอส่วนใหญ่

แม้แต่โคลนที่สามารถมีผลกระทบและในกรณีนี้OP Joeรายงาน:

[clone] ใช้งานได้ดีในขณะนี้

หมายเหตุ: หากมีบางอย่างผิดปกติที่ฝั่งเซิร์ฟเวอร์และหากเซิร์ฟเวอร์ใช้ Git 2.5+ (Q2 2558) ข้อความแสดงข้อผิดพลาดอาจชัดเจนกว่านี้
ดูที่ "การโคลน Git: สิ้นสุดระยะไกลวางสายโดยไม่คาดคิดลองเปลี่ยนpostBufferแต่ยังล้มเหลว "

Kulai ( ในความคิดเห็น ) ชี้ไปที่หน้า Git การแก้ไขปัญหา Atlassianซึ่งเพิ่ม:

Error code 56ระบุว่า curl ได้รับข้อผิดพลาดCURLE_RECV_ERRORซึ่งหมายความว่ามีปัญหาบางอย่างที่ทำให้ไม่สามารถรับข้อมูลในระหว่างกระบวนการโคลนได้
โดยทั่วไปเกิดจากการตั้งค่าเครือข่ายไฟร์วอลล์ไคลเอนต์ VPN หรือโปรแกรมป้องกันไวรัสที่ยกเลิกการเชื่อมต่อก่อนที่ข้อมูลทั้งหมดจะถูกถ่ายโอน

นอกจากนี้ยังกล่าวถึงตัวแปรสภาพแวดล้อมต่อไปนี้เพื่อช่วยในกระบวนการดีบัก

# Linux
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

#Windows
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

ด้วย Git 2.25.1 (ก.พ. 2020) คุณรู้เพิ่มเติมเกี่ยวกับhttp.postBuffer"การแก้ปัญหา" นี้

ดูคอมมิชชัน 7a2dc95 , ยอมรับ 1b13e90 (22 ม.ค. 2020) โดยbrian m คาร์ลสัน (bk2204 )
^{(ผสานโดยJunio ​​C Hamano - gitster- in 53a8329 , 30 Jan 2020)}
( การสนทนารายชื่อผู้รับจดหมาย Git )

docs: พูดถึงเมื่อเพิ่ม http.postBuffer มีค่า

^{ลงชื่อออกโดย: brian m คาร์ลสัน}

ผู้ใช้ในสถานการณ์ที่หลากหลายพบว่าตนเองมีปัญหาการพุช HTTP

บ่อยครั้งที่ปัญหาเหล่านี้เกิดจากซอฟต์แวร์ป้องกันไวรัส, การกรองพร็อกซีหรือสถานการณ์อื่น ๆ บางครั้งพวกเขาเกิดจากเครือข่ายที่ไม่สามารถไว้ใจได้ง่าย

อย่างไรก็ตามวิธีแก้ไขปัญหาทั่วไปสำหรับการพุช HTTP ที่พบทางออนไลน์คือการเพิ่ม http.postBuffer

สิ่งนี้ใช้ได้กับสถานการณ์ใด ๆ ที่กล่าวมาแล้วและมีประโยชน์ในกรณีที่มีขนาดเล็กและถูก จำกัด อย่างมาก: เป็นหลักเมื่อการเชื่อมต่อไม่รองรับ HTTP / 1.1 อย่างถูกต้อง

เอกสารเมื่อเพิ่มค่านี้เหมาะสมและสิ่งที่มันทำจริงและกีดกันผู้คนจากการใช้มันเป็นวิธีแก้ไขปัญหาทั่วไปสำหรับปัญหาการผลักเนื่องจากมันไม่มีประสิทธิภาพ

ดังนั้นเอกสารสำหรับgit config http.postBufferตอนนี้รวมถึง:

http.postBuffer

ขนาดสูงสุดในหน่วยไบต์ของบัฟเฟอร์ที่ใช้โดยการส่ง HTTP อัจฉริยะเมื่อ POSTing ข้อมูลไปยังระบบระยะไกล
สำหรับคำร้องขอที่ใหญ่กว่าขนาดบัฟเฟอร์นี้ HTTP / 1.1 และการเข้ารหัสการถ่ายโอน: chunked ถูกใช้เพื่อหลีกเลี่ยงการสร้างไฟล์แพ็คขนาดใหญ่ในเครื่อง
ค่าเริ่มต้นคือ 1 MiB ซึ่งเพียงพอสำหรับคำขอส่วนใหญ่

โปรดทราบว่าการเพิ่มขีด จำกัด นี้จะมีผลบังคับใช้สำหรับการปิดใช้งานการเข้ารหัสการถ่ายโอนแบบ chunked เท่านั้นดังนั้นควรใช้เฉพาะเมื่อเซิร์ฟเวอร์ระยะไกลหรือพร็อกซีสนับสนุน HTTP / 1.0 เท่านั้นหรือไม่สอดคล้องกับมาตรฐาน HTTP
Raising นี้ไม่ได้โดยทั่วไปโซลูชั่นที่มีประสิทธิภาพสำหรับปัญหาการผลักดันมากที่สุด แต่สามารถเพิ่มการใช้หน่วยความจำอย่างมีนัยสำคัญตั้งแต่บัฟเฟอร์ทั้งหมดจะถูกจัดสรรแม้สำหรับดันขนาดเล็ก

ข้อผิดพลาดเดียวกันกับ Bitbucket แก้ไขโดย

git config --global http.postBuffer 500M
git config --global http.maxRequestBuffer 100M
git config --global core.compression 0

เคล็ดลับ http.postBuffer ไม่ได้ผลสำหรับฉัน อย่างไรก็ตาม:

สำหรับคนอื่นที่ประสบปัญหานี้อาจเป็นปัญหากับ GnuTLS หากคุณตั้งค่าโหมด Verbose คุณอาจเห็นข้อผิดพลาดพื้นฐานมองบางอย่างตามบรรทัดของรหัสด้านล่าง

น่าเสียดายที่ทางออกเดียวของฉันคือการใช้ SSH

ฉันเห็นวิธีการโพสต์ที่อื่นเพื่อรวบรวม Git กับ OpenSSL แทน GnuTLS มีการรายงานข้อผิดพลาดการใช้งานสำหรับปัญหาคือที่นี่

GIT_CURL_VERBOSE=1 git clone https://github.com/django/django.git

Cloning into 'django'...
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * Connected to github.com (192.30.252.131) port 443 (#0)
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> GET /django/django.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept: */*
Accept-Encoding: gzip

Pragma: no-cache
< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:14 GMT

< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
* Connection #0 to host github.com left intact
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> POST /django/django.git/git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept-Encoding: gzip

Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Encoding: gzip
Content-Length: 2299
* upload completely sent off: 2299out of 2299 bytes

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:15 GMT

< Content-Type: application/x-git-upload-pack-result
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
remote: Counting objects: 232015, done.
remote: Compressing objects: 100% (65437/65437), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

ข้อสังเกต: การเปลี่ยนแปลงhttp.postBufferอาจต้องตั้งค่าไฟล์การกำหนดค่า Nginx เพื่อให้ gitlab ยอมรับขนาดร่างกายที่ใหญ่ขึ้นสำหรับไคลเอ็นต์โดยการปรับค่าของ client_max_body_size

แต่มีวิธีแก้ปัญหาหากคุณมีการเข้าถึงเครื่อง Gitlabgit bundleหรือเครื่องในเครือข่ายของตนและที่อยู่โดยการใช้ประโยชน์จาก

1. ไปที่ที่เก็บ git ของคุณบนเครื่องต้นทาง
2. วิ่ง git bundle create my-repo.bundle --all
3. ถ่ายโอน (เช่นด้วย rsync) ไฟล์ my-repo.bundle ไปยังเครื่องปลายทาง
4. บนเครื่องปลายทางให้เรียกใช้ git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

ดีที่สุด!

สิ่งเดียวที่ใช้ได้ผลสำหรับฉันคือการโคลน repo โดยใช้ลิงก์HTTPSแทนลิงก์SSH

หากคุณใช้ https และคุณได้รับข้อผิดพลาด

ฉันใช้ https แทน http และแก้ปัญหาของฉันได้

git config --global https.postBuffer 524288000

ขึ้นอยู่กับ คำตอบนี้ฉันลองทำตาม (ด้วย https url):

1. การโคลนเริ่มต้นของ repo:

git clone --depth 25 url-here

2. การดึงข้อมูลเพิ่มขึ้นสองครั้งต่อความลึกการลอง

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

... และต่อไป

3. ในที่สุด (เมื่อฉันคิดว่าพอเรียก) ฉันวิ่ง git fetch --unshallow - และมันก็เสร็จแล้ว

เห็นได้ชัดว่ากระบวนการใช้เวลามากขึ้น แต่ในกรณีของฉันการตั้งค่า http.postBufferและcore.compressionไม่ได้ช่วย

UPD : ฉันพบว่าการดึงข้อมูลผ่านsshใช้ได้กับทุกขนาด repo (ค้นพบโดยไม่ได้ตั้งใจ) ทำได้ด้วยgit clone <ssh url>เนื่องจากคุณได้สร้างคีย์ ssh แล้ว เมื่อเรียกคืน repo แล้วฉันจะเปลี่ยนที่อยู่ระยะไกลโดยใช้git remote set-url <https url to repo>

ฉันได้รับการแก้ไขหลังจากใช้คำสั่งด้านล่าง:

git repack -a -f -d --window=250 --depth=250

ฉันได้รับปัญหาเดียวกันฉันแก้ไขปัญหานี้ด้วยวิธีทดลองและข้อผิดพลาด ฉันเปลี่ยนค่า core.compression จนกว่าจะได้ผล

ฉันเริ่มต้นด้วย "git config - global core.compression 1" หลังจาก 3 ครั้ง

"git config - global core.compression 4" ได้ผลสำหรับฉัน

นี่เป็นเพราะปัญหาการเชื่อมต่ออินเทอร์เน็ตฉันต้องเผชิญกับปัญหาเดียวกัน ฉันทำสำเนารหัสตื้นโดยใช้

git clone --depth 1 //FORKLOCATION

ต่อมาไม่อนุญาตให้โคลนใช้

git fetch --unshallow

ใน/etc/resolv.confเพิ่มบรรทัดไปยังจุดสิ้นสุดของไฟล์

options single-request

ฉันต้องการผลักดันโซลูชั่นขนาด 219 MB แต่ฉันก็ไม่มีโชค

git config --global http.postBuffer 524288000

และอะไรคือจุดที่มีบัฟเฟอร์การโพสต์ 525 MB มันโง่ ดังนั้นฉันดูข้อผิดพลาดคอมไพล์ด้านล่าง:

Total 993 (delta 230), reused 0 (delta 0)
POST git-receive-pack (5173245 bytes)
error: fatal: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054

ดังนั้น git ต้องการโพสต์ 5 MB แล้วฉันทำ post buffer 6 MB และใช้งานได้

git config --global http.postBuffer 6291456

ฉันมีปัญหาเดียวกันและเกี่ยวข้องกับการเชื่อมต่ออินเทอร์เน็ตที่ไม่ดีดังนั้นหลังจากลองใช้การกำหนดค่า git แล้วฉันเพิ่งตัดการเชื่อมต่อจากเครือข่ายของฉันและเชื่อมต่ออีกครั้งและใช้งานได้!

ดูเหมือนว่าหลังจากการเชื่อมต่อขาดหายไป (หรือการกระทำที่ทำให้เกิดสถานการณ์นี้) คอมไพล์ก็ติดอยู่

ฉันหวังว่ามันจะช่วยให้ใครบางคนมากขึ้นที่นี่

ที่ดีที่สุด

ฉันก็มีปัญหาเดียวกันเหตุผลสำหรับปัญหานี้ก็คือคำอธิบายของ Kurtis เกี่ยวกับ GNUTLS

หากคุณมีเหตุผลเดียวกันและระบบของคุณคือ Ubuntu คุณสามารถแก้ปัญหานี้ได้โดยติดตั้ง git เวอร์ชันล่าสุดจากppa:git-core/ppaคำสั่งต่าง ๆ ดังต่อไปนี้

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get git

ฉันกำลังเผชิญปัญหานี้เมื่อโคลนข้อมูล (ผ่าน HTTP) จาก repo git ระยะไกลที่โฮสต์บนอินสแตนซ์ AWS EC2 ที่จัดการโดยยืดหยุ่นฝักถั่ว การโคลนเองก็ทำกับอินสแตนซ์ของ AWS EC2

ฉันลองวิธีแก้ปัญหาทั้งหมดข้างต้นและชุดค่าผสมของพวกเขา:

• การตั้งค่าของคอมไพล์ http.postBuffer
• การตั้งค่าhttp.maxrequestbuffer
• ปิดการบีบอัดคอมไพล์และลอง "ตื้น" git cloneแล้วgit fetch --unshallow- ดูอันตราย: ต้น EOF ร้ายแรง: ดัชนีแพ็คล้มเหลว
• การปรับการตั้งค่าหน่วยความจำ GIT - packedGitLimit และอื่น ๆ ดูที่นี่: ร้ายแรง: ต้น EOF ร้ายแรง: ดัชนีแพ็คล้มเหลว
• การปรับแต่งค่า nginx - ตั้งค่าclient_max_body_sizeทั้งค่าขนาดใหญ่และ 0 (ไม่ จำกัด จำนวน); การตั้งค่าproxy_request_buffering off;
• การตั้งค่า options single-requestใน /etc/resolv.conf
• การควบคุมปริมาณงานไคลเอนต์ git ด้วยหยด
• ใช้ strace สำหรับการติดตาม git clone
• กำลังพิจารณาปรับปรุงไคลเอ็นต์ git

หลังจากทั้งหมดนี้ฉันยังคงเผชิญปัญหาเดียวกันซ้ำแล้วซ้ำอีกจนกระทั่งพบว่าปัญหาอยู่ใน Elastic Load Balancer (ELB) ที่ตัดการเชื่อมต่อตัดการเชื่อมต่อ หลังจากเข้าถึงอินสแตนซ์ EC2 (โฮสติ้ง git repo) โดยตรงแทนที่จะไปผ่าน ELB ในที่สุดฉันก็สามารถโคลน repo git ได้! ฉันยังไม่แน่ใจว่าพารามิเตอร์ของ ELB (การหมดเวลา) ใดที่รับผิดชอบเรื่องนี้ดังนั้นฉันจึงยังต้องทำการวิจัย

UPDATE

ดูเหมือนว่าการเปลี่ยนแปลง นโยบายการระบายการเชื่อมต่อสำหรับ AWS Elastic Load Balancer โดยเพิ่มการหมดเวลาจาก 20 วินาทีเป็น 300 วินาทีเพื่อแก้ไขปัญหานี้ให้เรา

ความสัมพันธ์ระหว่าง git cloneข้อผิดพลาดและ "การระบายการเชื่อมต่อ" นั้นแปลกและไม่ชัดเจนสำหรับเรา อาจเป็นได้ว่าการเปลี่ยนแปลงการหมดเวลาการเชื่อมต่อทำให้เกิดการเปลี่ยนแปลงภายในบางอย่างในการกำหนดค่า ELB ที่แก้ไขปัญหาด้วยการปิดการเชื่อมต่อก่อนกำหนด

นี่คือคำถามที่เกี่ยวข้องในฟอรัม AWS (ยังไม่มีคำตอบ): https://forums.aws.amazon.com/thread.jspa?threadID=258572

ฉันมีปัญหาที่คล้ายกัน แต่กับงานไม้ไผ่ Bamboo ล้มเหลวในการทำโลคัลโลคัล (โลคัล แต่ผ่านพร็อกซี SSH) ของที่เก็บแคชฉันลบแคชและหลังจากนั้นก็ใช้งานได้ แต่ทุกครั้งที่พยายามลอกแบบจากแคชโลคัลมีความล้มเหลว ดูเหมือนว่าปัญหากับพร็อกซี SSH รุ่นไผ่ที่ไม่ได้คอมไพล์ต่อกัน

ฉันมีข้อผิดพลาดเดียวกันในขณะที่ใช้ BitBucket สิ่งที่ผมทำก็คือเอา https จาก URL ของ repo ของฉันและตั้งค่า URL HTTPโดยใช้

git remote set-url origin http://mj@bitbucket.org/mj/pt.git

แก้ไขได้ด้วยการตั้งค่าเราเตอร์ไร้สาย:

ฉันมีปัญหาเดียวกันเมื่อฉันอยู่ใน wifi ด้วยการตั้งค่า PPPoE (ล็อกอินอัตโนมัติโดยเราเตอร์ไร้สาย)

ความเร็วในการดาวน์โหลด Git ช้ามาก 15kb

packet_write_wait: การเชื่อมต่อกับพอร์ต 17.121.133.16 22: ท่อแตกร้ายแรง: ปลายรีโมตวางสายที่ร้ายแรงโดยไม่คาดคิด: EOF ก่อนถึงแก่ชีวิต: ดัชนีแพ็คล้มเหลว

วิธีแก้ไข: 1. เปลี่ยนการตั้งค่าเป็น Dynamic IP รีบูตเราเตอร์ไร้สาย 2. จากเว็บเบราว์เซอร์เข้าสู่พอร์ทัลผู้ให้บริการอินเทอร์เน็ต (อย่ากำหนดค่า PPPoE ล็อกอินอัตโนมัติจากเราเตอร์ไร้สาย)

หลังจากเปลี่ยนความเร็วในการดาวน์โหลด Git คือ 1.7MiB

วิธีนี้แก้ไขปัญหาของฉัน:

git clone --depth=20 https://repo.git -b master

เทคนิคข้างต้นไม่ได้ช่วยฉันเนื่องจาก repo มีขนาดใหญ่กว่าขนาด push สูงสุดที่อนุญาตให้ใช้ที่ github สิ่งที่ได้ผลคือคำแนะนำจากhttps://github.com/git-lfs/git-lfs/issues/3758ซึ่งแนะนำให้กดบิตทีละครั้ง:

หากสาขาของคุณมีประวัติอันยาวนานคุณสามารถลองทำคอมมิชชั่นได้ครั้งละน้อย (เช่น 2000) ด้วยวิธีดังนี้:

git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master

ที่จะเดินผ่านประวัติศาสตร์ของอาจารย์ผลักวัตถุ 2,000 ครั้ง (แน่นอนคุณสามารถแทนที่สาขาอื่นในทั้งสองที่ได้หากต้องการ) เมื่อเสร็จแล้วคุณควรจะสามารถผลักดันมาสเตอร์ได้ในครั้งสุดท้ายและสิ่งต่าง ๆ ควรเป็นข้อมูลล่าสุด หาก 2000 มีจำนวนมากเกินไปและคุณประสบปัญหาอีกครั้งคุณสามารถปรับจำนวนเพื่อให้มีขนาดเล็กลง

เสียเวลาเพียงไม่กี่ชั่วโมงในการลองใช้โซลูชันเหล่านี้ แต่ในที่สุดก็ติดตามสิ่งนี้กับ IPS ขององค์กร (Instrusion Protection System) ทำให้การเชื่อมต่อลดลงหลังจากถ่ายโอนข้อมูลจำนวนหนึ่ง

สำหรับแบนด์วิดท์ที่ใช้ร่วมกันพยายามโคลนเมื่อโหลดน้อย มิฉะนั้นลองด้วยการเชื่อมต่อความเร็วสูง หากยังไม่สามารถใช้งานได้โปรดใช้คำสั่งด้านล่าง

git config --global http.postBuffer 2048M
git config --global http.maxRequestBuffer 1024M
git config --global core.compression 9

git config --global ssh.postBuffer 2048M
git config --global ssh.maxRequestBuffer 1024M

git config --global pack.windowMemory 256m 
git config --global pack.packSizeLimit 256m

และลองโคลนอีกครั้ง คุณอาจต้องเปลี่ยนการตั้งค่าเหล่านั้นตามขนาดหน่วยความจำที่มีอยู่

อาจง่ายเหมือนปัญหาเซิร์ฟเวอร์ ถ้าใช้ GitHub ตรวจสอบhttps://twitter.com/githubstatus ฉันเห็นสิ่งนี้เป็นครั้งแรกในตอนนี้และค้นพบว่าGitHub กำลังส่ายไปส่ายมา ไม่กี่นาทีต่อมามันก็ทำงานได้ดีอีกครั้ง

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

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

ฉันประสบกับปัญหานี้โดยใช้ git ใน Kubuntu ฉันได้สังเกตเห็นยังความไม่แน่นอนโดยรวมในระบบเครือข่ายและพบว่าวิธีการแก้ปัญหา

ใน /etc/resolv.conf เพิ่มบรรทัดไปยังจุดสิ้นสุดของไฟล์

ตัวเลือกคำขอเดียว

ความล่าช้านี้คงที่ก่อนที่การแก้ปัญหาชื่อโดเมนและ git จะเริ่มทำงานอย่างมีเสน่ห์หลังจากนี้

ฉันพบปัญหาที่เกิดขึ้นกับไฟล์. netrc หากเป็นเช่นนั้นสำหรับคุณคุณสามารถทำสิ่งต่อไปนี้ได้:

เปิดไฟล์. netrc ของคุณและแก้ไขเพื่อรวมหนังสือรับรอง Github ชนิดnano ~/netrcหรือgedit ~/netrc

จากนั้นรวมสิ่งต่อไปนี้: * machine github.com

ชื่อผู้ใช้เข้าสู่ระบบ

รหัสผ่าน SECRET

เครื่อง api.github.com

ชื่อผู้ใช้เข้าสู่ระบบ

รหัสผ่าน SECRET *

คุณสามารถใส่รหัสผ่านดิบของคุณได้ที่นั่น แต่เพื่อความปลอดภัยให้สร้างโทเค็นรับรองความถูกต้องที่นี่github โทเค็นและวางแทนรหัสผ่านของคุณ

หวังว่านี่จะช่วยใครซักคน

อาจเป็นเพราะขนาดความมุ่งมั่นที่ถูกผลัก .. แบ่งจำนวนการกระทำตามขั้นตอนต่อไปนี้:

git log -5

ดู 5 คอมมิชชันล่าสุดและคุณจะรู้ว่าอันไหนที่ไม่ถูกผลักไปที่รีโมต เลือกรหัสกระทำและผลักดันการกระทำทั้งหมดจนถึงรหัสนั้น:

git push <remote_name> <commit_id>:<branch_name>

หมายเหตุ:ฉันเพิ่งตรวจสอบการกระทำของฉันซึ่งอาจมีขนาดที่ใหญ่ที่สุด; ก่อนผลักขึ้นจนแล้ว เคล็ดลับใช้งานได้ !!

ฉันกำลังผลักดันคอมไพล์จาก OS X El Capitan Mac ของฉัน ฉันได้รับข้อผิดพลาดเดียวกันฉันพยายามทุกอย่างเพื่อแก้ไขสิ่งที่ฉันพบใน google / stackoverflow เท่าที่มีความเกี่ยวข้องกับรุ่นฉันกำลังใช้ Github รุ่นล่าสุดที่ค่อนข้างเป็น 2.7.4 ฉันได้สร้างโครงการในระบบท้องถิ่นของฉันและฉันต้องการให้โครงการนี้เป็นแบบสาธารณะในบัญชี GitHub ของฉัน ขนาดโครงการไม่ประมาณ 8MB ฉันสังเกตเห็นว่าเมื่อฉันผลักไฟล์บางไฟล์ที่มีขนาดประมาณ 1.5MB มันก็ผลักอย่างถูกต้อง แต่ด้วยขนาดใหญ่ล้มเหลวสำหรับฉันด้วยข้อผิดพลาดเดียวกัน

ตัวเลือกเดียวที่ฉันมีคือการผลักดันการเปลี่ยนแปลงในหน่วย MB ตอนนี้ฉันผลักดันการเปลี่ยนแปลงทั้งหมดแล้ว นี่เป็นวิธีแก้ปัญหาสำหรับฉันจนกว่าฉันจะได้รับการแก้ไขสำหรับโซลูชันนี้

ดังนั้นคุณสามารถลองผลักดันการเปลี่ยนแปลงในหลายกระทำ หรือถ้าคุณมีหลายโฟลเดอร์คุณสามารถผลักดันการเปลี่ยนแปลงโดยแต่ละโฟลเดอร์ (ถ้าขนาดโฟลเดอร์ไม่ใหญ่)

หวังว่านี่จะช่วยให้คุณทำงานในโครงการอย่างต่อเนื่อง

ประสบปัญหาเดียวกันพยายามผสานกับสาขาอื่นและดึงจากพวกเขา มันใช้งานได้สำหรับฉันเหมือนกัน

ใช้sshแทนhttpมันไม่ใช่คำตอบที่ดีสำหรับคำถามนี้ แต่อย่างน้อยก็ใช้ได้กับฉัน