दूरस्थ अंत अनपेक्षित रूप से लटका दिया गया, जबकि क्लोन क्लोनिंग


278

gitकुछ समय के लिए रिपॉजिटरी को क्लोन करने की कोशिश करने के बाद मेरा क्लाइंट बार-बार होने वाली त्रुटि के साथ विफल हो जाता है।

यहां क्या मुद्दा हो सकता है?

नोट: मैंने अपनी SSH कुंजी को GIT होस्टिंग प्रदाता के साथ पंजीकृत किया है

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

क्या आप देख सकते हैं कि आपका git होस्टिंग प्रदाता ऑनलाइन है या नहीं?
कैप

@ यह ऑनलाइन है और नेटवर्क भी ठीक है। ऐसा लगता है कि कुछ समय बाद लगातार हो रहा है।
जो

6
क्या आप देख सकते हैं कि git config --global http.postBuffer 524288000आपके क्लोन पर कोई प्रभाव पड़ा है? इसमें ' error: RPC failed; result=56, HTTP code = 0' जैसे कोई अतिरिक्त त्रुटि संदेश है
VonC

@VonC - उपरोक्त आदेश को ठीक-ठीक निष्पादित किया गया, कंसोल पर कोई आउटपुट नहीं देखा गया।
जो

3
@ जो आप के बाद क्लोन करने में सक्षम हैं git config --global http.postBuffer 524288000?
VonC

जवाबों:


470

त्वरित समाधान:

इस तरह की त्रुटि के साथ, मैं आमतौर पर इसके द्वारा postBufferआकार बढ़ाकर शुरू करता हूं :

git config --global http.postBuffer 524288000

(मूल्य को दोगुना करने के लिए रिपोर्ट के नीचे कुछ टिप्पणियां):

git config --global http.postBuffer 1048576000

अधिक जानकारी:

से git configआदमी पेज , http.postBufferके बारे में है:

स्मार्ट HTTP द्वारा उपयोग किए जाने वाले बफर के बाइट्स में अधिकतम आकार जब दूरस्थ सिस्टम में डेटा पोस्ट करता है।
इस बफ़र आकार, HTTP / 1.1 से बड़े अनुरोधों के लिए और Transfer-Encoding: chunkedस्थानीय स्तर पर एक बड़े पैमाने पर पैक फ़ाइल बनाने से बचने के लिए उपयोग किया जाता है। डिफ़ॉल्ट 1 MiB है, जो अधिकांश अनुरोधों के लिए पर्याप्त है।

यहां तक ​​कि क्लोन के लिए, जिसका प्रभाव हो सकता है, और इस उदाहरण में, ओपी जो रिपोर्ट करता है:

[क्लोन] अब ठीक काम करता है


नोट: यदि सर्वर की तरफ कुछ गलत हुआ है, और यदि सर्वर Git 2.5+ (Q2 2015) का उपयोग करता है, तो त्रुटि संदेश अधिक स्पष्ट हो सकता है।
देखें " गिट क्लोनिंग: रिमोट एंड अनपेक्षित रूप से लटका हुआ, बदलने की कोशिश की postBufferलेकिन अभी भी असफल "।


कुलताई ( टिप्पणियों में ) इस एटलसियन ट्रबलशूटिंग गिट पेज की ओर इशारा करती है , जो जोड़ता है:

Error code 56इंगित करता है कि कर्ल त्रुटि प्राप्त करता है, CURLE_RECV_ERRORजिसका अर्थ है कि कुछ समस्या थी जो डेटा को क्लोनिंग प्रक्रिया के दौरान प्राप्त होने से रोकती थी।
आमतौर पर यह नेटवर्क सेटिंग, फ़ायरवॉल, वीपीएन क्लाइंट या एंटी-वायरस के कारण होता है जो सभी डेटा को स्थानांतरित करने से पहले कनेक्शन को समाप्त कर रहा है।

इसमें डिबगिंग प्रक्रिया के साथ मदद करने के लिए निम्नलिखित पर्यावरण चर का भी उल्लेख है।

# 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

2.25.1 (फरवरी 2020) के साथ, आप इस http.postBuffer"समाधान" के बारे में अधिक जानते हैं।

देखें 7a2dc95 , 1B13e90 (22 जनवरी 2020) को brian मी। कार्लसन ( bk2204)
(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध 53a8329 , 30 जनवरी 2020)
( Git मेलिंग सूची चर्चा )

docs: http.postBuffer को बढ़ाते समय उल्लेख मूल्यवान है

हस्ताक्षरित-बंद: brian m। कार्लसन

विभिन्न प्रकार की स्थितियों में उपयोगकर्ता स्वयं को HTTP पुश समस्याओं के साथ पाते हैं।

अक्सर ये मुद्दे एंटीवायरस सॉफ़्टवेयर, फ़िल्टरिंग परदे के पीछे, या अन्य मानव-में-मध्य स्थितियों के कारण होते हैं; अन्य बार, वे नेटवर्क की सरल अविश्वसनीयता के कारण होते हैं।

हालाँकि, HTTP पुश समस्याओं का एक सामान्य समाधान http.postBuffer को बढ़ाना है।

यह पूर्वोक्त स्थितियों में से किसी के लिए काम करता है और केवल छोटे, अत्यधिक प्रतिबंधित मामलों की संख्या में उपयोगी है: अनिवार्य रूप से, जब कनेक्शन ठीक से HTTP / 1.1 का समर्थन नहीं करता है।

इस मूल्य को बढ़ाते समय दस्तावेज़ उपयुक्त है और यह वास्तव में क्या करता है, और लोगों को धक्का समस्याओं के लिए एक सामान्य समाधान के रूप में उपयोग करने से हतोत्साहित करता है, क्योंकि यह वहां प्रभावी नहीं है।

तो अब के लिए प्रलेखन में git config http.postBufferशामिल हैं:

http.postBuffer

स्मार्ट HTTP द्वारा उपयोग किए जाने वाले बफर के बाइट्स में अधिकतम आकार जब दूरस्थ सिस्टम में डेटा पोस्ट करता है।
इस बफ़र आकार से बड़े अनुरोधों के लिए, HTTP / 1.1 और ट्रांसफ़र-एन्कोडिंग: chunked का उपयोग स्थानीय स्तर पर बड़े पैमाने पर पैक फ़ाइल बनाने से बचने के लिए किया जाता है।
डिफ़ॉल्ट 1 MiB है, जो अधिकांश अनुरोधों के लिए पर्याप्त है।

ध्यान दें कि यह सीमा बढ़ाना केवल ट्रांसफ़र किए गए एन्कोडिंग को अक्षम करने के लिए प्रभावी है और इसलिए इसका उपयोग केवल उसी स्थान पर किया जाना चाहिए जहां दूरस्थ सर्वर या प्रॉक्सी केवल HTTP / 1.0 का समर्थन करता है या HTTP मानक के साथ गैर-योग्य है।
यह उठाना, सामान्य रूप से, अधिकांश पुश समस्याओं के लिए एक प्रभावी समाधान नहीं है, लेकिन मेमोरी की खपत को काफी बढ़ा सकता है क्योंकि पूरे बफर को छोटे पुश के लिए भी आवंटित किया जाता है


2
यह मेरे लिए भी काम कर रहा है, लेकिन जब मैं "स्मार्ट HTTP ट्रांसपोर्ट" एक ट्रांसफर ओवर में शामिल होता हूं तो मैं थोड़ा भ्रमित हो जाता हूं ssh://
delicateLatticeworkFever

4
धन्यवाद काम किया, लेकिन जवाब में दिए गए मूल्य से दोगुना है।
लोलिता रत्नायके

10
हो सकता है कि दस्तावेज़ गलत हो, लेकिन जब आप HTTP पर क्लोन / क्लोन लाते हैं तो POST क्या होता है। मैं इस बात को लेकर उलझन में हूं कि postBufferसेटिंग का क्लोन या भ्रूण पर कोई प्रभाव क्यों पड़ता है।
void.pointer

PostBuffer को उठाना और https का उपयोग करने से मुझे मदद मिलती है। धन्यवाद, वॉन
योहानन

2
@Astravagrant ठीक है, मैंने उस मूल्य को अधिक दृश्यमान बनाने के लिए उत्तर अपडेट किया है।
VonC

32

Bitbucket के साथ एक ही त्रुटि। द्वारा तय किया गया

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

यह एक कनेक्शन रीसेट त्रुटि और इस त्रुटि वाले मेरे मुद्दे को हल किया: घातक: दूरस्थ अंत अप्रत्याशित रूप से लटका दिया
सम्राट क्रूसर

इससे मेरी समस्या हल हो गई! ओमग, मैंने पूरे इंटरनेट पर देखा, धन्यवाद! <3
सिल्वोन

17

Http.postBuffer ट्रिक ने मेरे लिए काम नहीं किया । तथापि:

इस समस्या का अनुभव करने वाले अन्य लोगों के लिए, यह GnuTLS के साथ एक समस्या हो सकती है। यदि आप वर्बोज़ मोड सेट करते हैं, तो आपको नीचे दी गई कोड की लाइनों के साथ अंतर्निहित त्रुटि दिख सकती है।

दुर्भाग्य से, मेरा अब तक का एकमात्र समाधान SSH का उपयोग करना है।

मैंने एक समाधान देखा है कि GSSTLS के बजाय OpenSSL के साथ Git को संकलित करने के लिए कहीं और पोस्ट किया गया है। इस मुद्दे के लिए एक सक्रिय बग रिपोर्ट है

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

3
मुझे आपकी तरह ही वर्बोज़ लॉग मिलता है। लेकिन बड़े पोस्टबफ़र मान का उपयोग करके हल किया गया।
suiwenfeng

3
git config --global http.postBuffer 100000000000000000000000000000000000
suiwenfeng

"Http.postbuffer: रेंज से बाहर" के लिए नए जिट संस्करण "घातक: खराब न्यूमेरिक कॉन्फिगर वैल्यू '100000000000' के कारण फेल हो जाते हैं, लेकिन कॉन्फिग वैल्यू सेट करने से मेरे मामले में मदद नहीं मिलती है।
कार्ल रिक्टर

सबसे बड़ा आकार जो मैं प्राप्त कर सकता हूं वह है100000000000000
nhoxbypass

8

Obs .: बदलने http.postBufferभी client_max_body_size का मूल्य ग्राहक के लिए बड़ा शरीर का आकार बहुत स्वीकार करने के लिए ट्यूनिंग द्वारा gitlab के लिए Nginx विन्यास फाइल स्थापित करने के लिए आवश्यकता हो सकती है।

हालाँकि, यदि आपके पास Gitlab मशीन या उसके नेटवर्क में किसी मशीन तक पहुँच है , और इसका उपयोग करने से वर्कअराउंड है git bundle

  1. स्रोत मशीन पर आपके गिट रिपॉजिटरी में जाएं
  2. Daud 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

शुभकामनाएं!


7

मेरे लिए काम करने वाली एकमात्र चीज़ SSH लिंक के बजाय HTTPS लिंक का उपयोग करके रेपो को क्लोन करना था ।


5

यदि आप https का उपयोग कर रहे हैं और आपको त्रुटि मिल रही है।

मैंने http के बजाय https का उपयोग किया और इसने मेरी समस्या हल कर दी

git config --global https.postBuffer 524288000

मेरे मामले में यह http.postBuffer के साथ काम नहीं किया था, इसलिए मैंने आपके द्वारा सुझाए गए https.postBuffer का उपयोग करने की कोशिश की। यह समाधान काम कर गया। धन्यवाद!
पास्कुट

अगर मैं ssh का उपयोग कर रहा हूँ तो क्या होगा? मैं http / https पर नहीं जा सकता।
RobisonSantos

5

इस उत्तर के आधार पर , मैंने निम्नलिखित की कोशिश की (https url के साथ):

  1. रेपो का प्रारंभिक क्लोनिंग:

git clone --depth 25 url-here

  1. प्रति प्रयास गहराई से दो बार बढ़ने के साथ प्राप्त होता है:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...और इसी तरह

  1. अंततः (जब मुझे लगता है कि पर्याप्त है) मैं दौड़ता हूं git fetch --unshallow- और यह किया जाता है।

इस प्रक्रिया में स्पष्ट रूप से अधिक समय लगता है, लेकिन मेरे मामले में सेटिंग http.postBufferऔर core.compressionमदद नहीं की।

UPD : मुझे पता चला कि ssh के माध्यम से किसी भी रेपो आकार (गलती से खोजा गया) के लिए काम git clone <ssh url>कर रहा है, जिसे देखते हुए आपने ssh कीज़ बनाई हैं। एक बार रेपो लाने के बाद, मैं रिमोट एड्रेस का उपयोग कर बदल देता हूंgit remote set-url <https url to repo>


4

नीचे दिए गए आदेश का उपयोग करने के बाद मुझे समाधान मिला:

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


4
आप कैसे चलाएंगे कि जब क्लोन ने अभी तक स्थानीय गिट रेपो नहीं बनाया है?
ल्यूसिडब्रोट

4

मुझे एक ही मुद्दा मिला, मैंने इसे परीक्षण और त्रुटि विधि के साथ तय किया। जब तक यह काम करता है मैंने core.compression मान बदल दिया है।

मैंने 3 प्रयासों के बाद "git config --global core.compression 1" के साथ शुरुआत की

"git config --global core.compression 4" ने मेरे लिए काम किया।


4

यह इंटरनेट कनेक्टिविटी के मुद्दे के कारण है, मैंने उसी मुद्दे का सामना किया। मैंने कोड का उपयोग करके उथली प्रतिलिपि बनाई

git clone --depth 1 //FORKLOCATION

बाद में क्लोन का उपयोग करके अनचेक कर दिया

git fetch --unshallow

2

में /etc/resolv.confफ़ाइल के अंत में पंक्ति जोड़ें

options single-request

यदि पोस्टबफ़र मदद नहीं करता है, तो यह उत्तर वह है जो मैं अगले प्रयास करने का सुझाव देता हूं, जैसा कि मेरे लिए काम किया।
खान

2

खैर, मैं एक 219 एमबी समाधान को आगे बढ़ाना चाहता था, लेकिन मुझे कोई भाग्य नहीं था

git config --global http.postBuffer 524288000

और फिर भी 525 एमबी पोस्ट बफर होने की क्या बात है? यह मूर्खता है। तो मैं नीचे त्रुटि त्रुटि को देखा:

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 पोस्ट किया जाए, तो मैंने पोस्ट को 6 MB का बफर बना दिया, और यह काम करता है

git config --global http.postBuffer 6291456

इसका कोई मतलब नहीं है। मैंने अपने रेपो साइज़ को देखा जो 15 mb का है। Ssh और HTTPS दोनों ने एक ही त्रुटि की शिकायत की, ssh कम मददगार था। मैंने जीथब से मुद्दों के बिना बड़ी परियोजनाओं को क्लोन किया है, यह एक बिटबकेट पर था जो सिर्फ बड़ी परियोजनाओं को पसंद नहीं करता है और डाउनलोड करने के लिए धीमा है। गिटलैब पर एक ही बात होती है। कुछ भी सेट करने से समस्या हल नहीं होगी। यहाँ समस्या रिमोट के साथ है। 15 मीटर के मेरे रेपो साइज़ के करीब मेरे पोस्टबफ़र को सेट करने के लिए जीथब में ले जाने से मुझे ऐसा लग रहा था, मुझे विश्वास नहीं है कि यह अभी भी पूर्ण समाधान है।
अभिषेक दुजारी

git config --global http.postBuffer 157286400, मैंने इसे बफ़र में सेट किया है, और मेरी वाईफ़ाई को बदल दिया है।
ram880

2

मेरे पास एक ही मुद्दा था और यह एक खराब इंटरनेट कनेक्शन से संबंधित था, इसलिए कुछ गिट कॉन्फ़िगरेशन के साथ प्रयास करने के बाद, मैंने अभी अपने नेटवर्क से डिस्कनेक्ट किया है और फिर से जुड़ा हुआ है और यह काम करता है!।

ऐसा लगता है कि कनेक्शन खो जाने के बाद (या इस स्थिति में आग लगाने वाली कार्रवाई), गिट फंस गया है।

मुझे उम्मीद है कि यह यहाँ किसी के लिए एक मदद हो सकती है।

श्रेष्ठ,


2

मुझे भी यही समस्या थी। इस समस्या का कारण कर्टिस के GNUTLS के बारे में वर्णन है।

यदि आपके पास भी यही कारण है और आपका सिस्टम उबंटू है, तो आप git के नवीनतम संस्करण को स्थापित करके इस समस्या को हल कर सकते ppa:git-core/ppaहैं। आदेश नीचे दिए गए हैं।

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

apt-get git??
ग्लेन

2

मैं इस मुद्दे का सामना कर रहा था जब AWS EC2 उदाहरण पर होस्ट किए गए दूरस्थ git रेपो से लोचदार बीनकल द्वारा प्रबंधित डेटा (HTTP के माध्यम से) क्लोनिंग किया गया था। क्लोनिंग स्वयं भी AWS EC2 उदाहरण पर की गई थी।

मैंने उपरोक्त सभी समाधानों और उनके संयोजनों की कोशिश की:

  • सेटिंग है http.postBuffer
  • स्थापनाhttp.maxrequestbuffer
  • जीआईटी संपीड़न को बंद करने और "उथले" की कोशिश करने git cloneऔर फिर git fetch --unshallow- घातक देखें : प्रारंभिक ईओएफ घातक: सूचकांक-पैक विफल
  • ट्यूनिंग GIT मेमोरी सेटिंग्स - packedGitLimit एट अल, यहां देखें: घातक: प्रारंभिक EOF घातक: इंडेक्स-पैक विफल
  • ट्यूनिंग नेग्नेक्स कॉन्फ़िगरेशन - client_max_body_sizeबड़े मूल्य और 0 (असीमित) दोनों के लिए सेटिंग ; स्थापनाproxy_request_buffering off;
  • स्थापना options single-request/etc/resolv.conf में
  • साथ throughput Git ग्राहक थ्रॉटल मिलने
  • अनुरेखण के लिए स्ट्रेस का उपयोग करना git clone
  • git क्लाइंट के अपडेट पर विचार करना

इस सब के बाद, मैं अभी भी बार-बार एक ही मुद्दे का सामना कर रहा था, जब तक कि मुझे यह पता नहीं चला कि यह मुद्दा कनेक्शन को काटने वाले इलास्टिक लोड बैलेंसर (ईएलबी) में है । EC2 उदाहरण (एक होस्टिंग git रेपो) तक पहुँचने के बाद सीधे ELB के माध्यम से जाने के बजाय मैं आखिरकार रेपो क्लोन करने में कामयाब रहा! मुझे अभी भी यकीन नहीं है कि इसके लिए कौन से ईएलबी (टाइमआउट) पैरामीटर जिम्मेदार हैं, इसलिए मुझे अभी भी कुछ शोध करना है।

अपडेट करें

ऐसा लगता है कि कनेक्शन बदलना नीति को बदलना एडब्ल्यूएस इलास्टिक लोड बैलेंसर के लिए 20 सेकंड से 300 सेकंड तक के समय के लिए को हमारे लिए इस मुद्दे को हल करता है।

git cloneत्रुटियों और "कनेक्शन जल निकासी" के बीच का संबंध हमारे लिए अजीब और स्पष्ट नहीं है। यह हो सकता है कि कनेक्शन की समय-सीमा में समय-समय पर होने वाली निकासी में बदलाव के कारण ईएलबी कॉन्फ़िगरेशन में कुछ आंतरिक परिवर्तन हुए, जिसने समय से पहले कनेक्शन को बंद कर दिया।

यह AWS फोरम पर संबंधित प्रश्न है (अभी तक कोई जवाब नहीं): https://forums.aws.amazon.com/thread.jspa?threadID=258572


मेरे उत्तर की तुलना में अच्छी पकड़, अधिक विशिष्ट। +1
वॉनसी

1

मुझे एक समान समस्या थी, लेकिन एक बांस की नौकरी के साथ। बांस एक कैश्ड रिपॉजिटरी का एक स्थानीय क्लोन (स्थानीय लेकिन एक एसएसएच प्रॉक्सी पर) करने में विफल रहा था, मैंने कैश को हटा दिया और उसके बाद यह काम किया, लेकिन किसी भी समय यह स्थानीय कैश से क्लोन करने की कोशिश करता है एक विफलता है। एसएसएच प्रॉक्सी के बांस संस्करण के साथ एक समस्या की तरह लगता है प्रति सेत नहीं।


1

BitBucket का उपयोग करते समय मेरे पास एक ही त्रुटि है। मैंने जो किया वह मेरे रेपो के URL से https हटा दिया गया और उपयोग करने वाले URL को सेट कर दिया HTTP

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

1

वाईफ़ाई रूटर सेटिंग के साथ हल:

मुझे वही मुद्दा मिला जब मैं सेटिंग्स पीपीपीओई (वाईफाई राउटर द्वारा ऑटो लॉगिन) के साथ वाईफाई में हूं।

Git डाउनलोड गति बहुत धीमी है 15kb।

packet_write_wait: 17.121.133.16 पोर्ट 22 के लिए कनेक्शन: टूटी हुई पाइप घातक: दूरस्थ अंत अप्रत्याशित रूप से घातक हो गया: प्रारंभिक EOF घातक: इंडेक्स-पैक विफल

समाधान: 1. डायनेमिक आईपी में बदली हुई सेटिंग, वाईफाई राउटर को रिबूट करें। 2. वेब ब्राउज़र लॉगिन से इंटरनेट सेवा प्रदाता पोर्टल (पीपीपीओई को कॉन्फ़िगर न करें, वाईफाई राउटर से ऑटो लॉगिन)।

Git डाउनलोड गति बदलने के बाद 1.7MiB है।


1

इससे मेरी समस्या हल हो गई:

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

1

ऊपर दिए गए ट्रिक ने मेरी मदद नहीं की, क्योंकि रेपो गितुब में अनुमत अधिकतम पुश आकार से बड़ा था। क्या काम किया था 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

यह एक समय में 2000 वस्तुओं को धकेलते हुए, गुरु के इतिहास से गुजरेगा। (आप, निश्चित रूप से, यदि आप चाहें तो दोनों स्थानों में एक अलग शाखा का विकल्प चुन सकते हैं।) जब ऐसा किया जाता है, तो आपको एक अंतिम समय में मास्टर को पुश करने में सक्षम होना चाहिए, और चीजें अप टू डेट होनी चाहिए। यदि 2000 बहुत अधिक है और आपने समस्या को फिर से मारा है, तो आप संख्या को समायोजित कर सकते हैं, इसलिए यह छोटा है।


मेरे 8 साल पुराने जवाब का दिलचस्प विकल्प। Upvoted।
VonC

1

इन समाधानों में से कुछ को आजमाते हुए कुछ घंटे बर्बाद हो गए लेकिन अंततः एक निश्चित डेटा स्थानांतरित होने के बाद कनेक्शन को छोड़ने वाले कॉर्पोरेट IPS (इंस्ट्रक्शन प्रोटेक्शन सिस्टम) को यह पता चला।


1

साझा बैंडविड्थ के लिए लोड कम होने पर क्लोन करने का प्रयास करें। अन्यथा, उच्च गति कनेक्शन के साथ प्रयास करें। यदि फिर भी काम नहीं करता है, तो कृपया नीचे दिए गए आदेश का उपयोग करें,

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

और फिर से क्लोन करने की कोशिश करें। आपको अपने उपलब्ध स्मृति आकार के अनुसार उन सेटिंग्स को बदलने की आवश्यकता हो सकती है।


0

यह सर्वर समस्या की तरह सरल हो सकता है। यदि GitHub का उपयोग कर रहे हैं, तो https://twitter.com/githubstatus देखें । मैंने इसे अभी पहली बार देखा और गीथहब के वोबेल होने का पता लगाया । कुछ मिनट बाद इसने फिर से काम किया।


0

इसने मेरे लिए काम किया, Googles नेमसर्वर की स्थापना की क्योंकि कोई भी मानक नेमसर्वर निर्दिष्ट नहीं किया गया था, इसके बाद नेटवर्किंग को फिर से शुरू किया गया:

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

0

मैंने कुबंटू में गिट का उपयोग करके इस समस्या का सामना किया। मैंने नेटवर्किंग में समग्र अस्थिरता पर भी ध्यान दिया है और एक समाधान पाया है ।

in /etc/resolv.conf फ़ाइल के अंत में लाइन जोड़ें

विकल्प एकल-अनुरोध

हर डोमेन नेम रिज़ॉल्यूशन से पहले यह निश्चित देरी हुई और इसके बाद आकर्षण की तरह काम करना शुरू कर दिया।


0

मुझे अपनी समस्या .netrc फ़ाइल के साथ मिल गई, यदि आपके लिए भी ऐसा है तो आप निम्न कार्य कर सकते हैं:

अपनी .netrc फ़ाइल खोलें और इसे github क्रेडेंशियल्स शामिल करने के लिए संपादित करें। टाइप nano ~/netrcयाgedit ~/netrc

फिर निम्नलिखित शामिल करें: * मशीन github.com

लॉग इन यूज़रनेम

पासवर्ड SECRET

मशीन api.github.com

लॉग इन यूज़रनेम

पासवर्ड SECRET *

आप वहां अपना कच्चा पासवर्ड शामिल कर सकते हैं, लेकिन सुरक्षा उद्देश्यों के लिए, यहाँ पर एक टोकन टाइप करें और इसे अपने पासवर्ड के स्थान पर चिपकाएँ।

आशा है कि यह किसी की मदद करता है


0

हो सकता है कि यह कमिट्स के आकार की वजह से हो रहा हो .. जिसे निम्न चरणों द्वारा कमिट्स की संख्या में ब्रेकडाउन करें:

git log -5

पिछले 5 कमिट्स देखें और आपको पता चल जाएगा कि किन लोगों को रिमोट से धक्का नहीं दिया गया है। एक कमेटी आईडी चुनें और उस आईडी पर आने वाले सभी कमेंट्स को पुश करें:

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

नोट: मैंने सिर्फ अपनी प्रतिबद्धता की जाँच की जो सबसे बड़ा आकार हो सकता है; पहले तो धक्का दिया। चाल काम कर गई। !!


0

मैं अपने OS X El Capitan मैक से git पुश कर रहा था। मुझे वही त्रुटि मिल रही थी, मैंने सब कुछ ठीक करने की कोशिश की, जो मुझे google / stackoverflow पर मिला। जहाँ तक संस्करण का संबंध है मैं काफी नवीनतम संस्करण github का उपयोग कर रहा हूँ जो कि 2.7.4 है। मैंने अपने स्थानीय सिस्टम में एक प्रोजेक्ट बनाया है, और मैं चाहता था कि यह मेरे जीथब खाते में सार्वजनिक हो। परियोजना का आकार लगभग 8 एमबी नहीं था। मैंने देखा कि जब मैं 1.5MB के आसपास आकार की कुछ फ़ाइलों को धक्का दे रहा था, तो यह ठीक से धक्का दे रहा था, लेकिन बड़े आकार के साथ मेरे लिए असफल रहा, उसी त्रुटि के साथ,

मेरे पास केवल एक विकल्प था कि मैं एमबी के चंक में बदलावों को आगे बढ़ाऊं। अब मैंने सभी बदलावों को आगे बढ़ाया है। मेरे लिए यह समाधान है जब तक कि मैं इस समाधान के लिए ठीक नहीं हो जाता।

इसलिए आप मल्टीपल कमिट में बदलाव को आगे बढ़ाने की कोशिश कर सकते हैं। या यदि आपके पास एक से अधिक फ़ोल्डर हैं, तो आप प्रत्येक फ़ोल्डर द्वारा परिवर्तन को धक्का दे सकते हैं (यदि फ़ोल्डर का आकार बड़ा नहीं है)।

आशा है कि यह आपको परियोजना पर लगातार काम करने में मदद करेगा।


0

उसी समस्या का सामना करते हुए, दूसरी शाखा के साथ विलय करने और उनसे एक खींचने का प्रयास करें। यह मेरे लिए ही काम करता है।


0

sshइसके बजाय का उपयोग करें http, यह इस प्रश्न के लिए एक अच्छा जवाब नहीं है, लेकिन कम से कम यह मेरे लिए काम करता है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.