গিট ক্লোনিংয়ের সময় দূরবর্তী প্রান্তটি অপ্রত্যাশিতভাবে স্তব্ধ হয়ে গিয়েছিল

Question

আমার gitক্লায়েন্ট বারবার কিছু সময়ের জন্য ভান্ডারটি ক্লোন করার চেষ্টা করার পরে নিম্নলিখিত ত্রুটিটি দিয়ে বার বার ব্যর্থ হয়।

এখানে সমস্যা কি হতে পারে?

দ্রষ্টব্য: আমি আমার এসএসএইচ কীটি জিআইটি হোস্টিং সরবরাহকারীর সাথে নিবন্ধভুক্ত করেছি

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

Comments

আপনার গিট হোস্টিং সরবরাহকারী অনলাইনে আছে কিনা তা পরীক্ষা করতে পারেন?

— ক্যাপস

@ ক্যাপস এটি অনলাইন এবং নেটওয়ার্কও ভাল also কিছুটা সময় পরে ধারাবাহিকভাবে ঘটেছিল বলে মনে হয়।

— জো

git config --global http.postBuffer 524288000আপনার ক্লোনটির কোনও প্রভাব আছে কিনা তা আপনি পরীক্ষা করতে পারেন ? error: RPC failed; result=56, HTTP code = 0

— এটিতে

@ ভনসি - উপরের কমান্ডটি ঠিক জরিমানা করা হয়েছে, কনসোলে কোনও আউটপুট দেখেনি।

— জো

@ জো আপনি কি পরে ক্লোন করতে পারবেন git config --global http.postBuffer 524288000?

— ভনসি

Answer 1

দ্রুত সমাধান:

এই ধরণের ত্রুটি দিয়ে, আমি সাধারণত উত্থাপনের মাধ্যমে শুরু করি postBuffer আকারটি :

git config --global http.postBuffer 524288000

(নীচে কিছু মন্তব্য মূল্য দ্বিগুণ করার বিষয়ে রয়েছে):

git config --global http.postBuffer 1048576000

অধিক তথ্য:

থেকে git configman পৃষ্ঠা , http.postBufferসম্পর্কে হল:

দূরবর্তী সিস্টেমে ডেটা পোষ্ট করার সময় স্মার্ট এইচটিটিপি পরিবহনের মাধ্যমে ব্যবহৃত বাফারের সর্বাধিক আকার
এই বাফার আকারের চেয়ে বড় অনুরোধগুলির জন্য, HTTP / 1.1 এবং Transfer-Encoding: chunkedস্থানীয়ভাবে একটি বৃহত প্যাক ফাইল তৈরি এড়াতে ব্যবহৃত হয়। ডিফল্টটি 1 এমআইবি, যা বেশিরভাগ অনুরোধের জন্য যথেষ্ট।

এমনকি ক্লোনটির জন্যও এর একটি প্রভাব থাকতে পারে এবং এই পরিস্থিতিতে ওপি জো রিপোর্ট করেছেন:

[ক্লোন] এখন ঠিকঠাক কাজ করে

---

দ্রষ্টব্য: যদি সার্ভারের দিক থেকে কিছু ভুল হয়ে যায় এবং সার্ভারটি যদি গিট 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

---

গিট ২.২৫.১ (ফেব্রুয়ারি ২০২০) এর সাথে, আপনি এই সম্পর্কে আরও জানুন http.postBuffer "সমাধান"

কমিট 7a2dc95 দেখুন , প্রতিশ্রুতিবদ্ধ 1b13e90 (22 জানুয়ারী 2020) দ্বারা ব্রায়ান এম। কার্লসন ( bk2204) ।
^{(দ্বারা একীভূত junio সি Hamano - gitster- মধ্যে কমিট 53a8329 , 30 জানুয়ারী 2020)}
( গীত ডাক তালিকা বিষয়ক আলোচনা )

docs: উল্লেখ যখন http.postBuffer বৃদ্ধি মূল্যবান

^{সাইন-অফ-বাই: ব্রায়ান মি। কার্লসন}

বিভিন্ন পরিস্থিতিতে ব্যবহারকারীরা এইচটিটিপি পুশ সমস্যায় নিজেকে আবিষ্কার করেন।

প্রায়শই এই সমস্যাগুলি অ্যান্টিভাইরাস সফ্টওয়্যার, ফিল্টারিং প্রক্সি বা মাঝারি পরিস্থিতিতে থাকা অন্যান্য ম্যান-ইন-এর কারণে হয়; অন্যান্য সময়ে, এগুলি নেটওয়ার্কের অবিশ্বাস্যতার কারণে হয়।

তবে অনলাইনে পাওয়া HTTP পুশ সমস্যার একটি সাধারণ সমাধান হ'ল http.postBuffer বৃদ্ধি করা increase

এটি উল্লিখিত অবস্থার কোনওটির জন্যই কাজ করে না এবং কেবলমাত্র সংক্ষিপ্ত, অত্যন্ত সীমিত সংখ্যক ক্ষেত্রেই কার্যকর: মূলত, যখন সংযোগটি HTTP / 1.1 সমর্থন করে না।

এই মানটি উত্থাপন করার সময় নথি উপযুক্ত এবং এটি আসলে কী করে, এবং এটি পুশ সমস্যার সাধারণ সমাধান হিসাবে এটি ব্যবহার থেকে নিরুৎসাহিত করে, কারণ এটি কার্যকর হয় না।

সুতরাং git config http.postBufferএখনকার ডকুমেন্টেশনের মধ্যে রয়েছে:

http.postBuffer

দূরবর্তী সিস্টেমে ডেটা পোষ্ট করার সময় স্মার্ট এইচটিটিপি পরিবহনের মাধ্যমে ব্যবহৃত বাফারের সর্বাধিক আকার
এই বাফার আকারের চেয়ে বড় অনুরোধগুলির জন্য, HTTP / 1.1 এবং স্থানান্তর-এনকোডিং: ছাঁকানো স্থানীয়ভাবে একটি বিশাল প্যাক ফাইল তৈরি এড়াতে ব্যবহৃত হয়।
ডিফল্ট হ'ল 1 এমআইবি, যা বেশিরভাগ অনুরোধের জন্য জারিযোগ্য।

নোট করুন যে এই সীমাটি বাড়ানো কেবল ছিন্নমূল ট্রান্সফার এনকোডিং নিষ্ক্রিয় করার জন্য কার্যকর এবং তাই কেবল তখনই ব্যবহার করা উচিত যেখানে দূরবর্তী সার্ভার বা প্রক্সি কেবল এইচটিটিপি / 1.0 সমর্থন করে বা এইচটিটিপি মানের সাথে সঙ্গতিপূর্ণ নয়।
এটি উত্থাপন, সাধারণভাবে, বেশিরভাগ ধাক্কা সমস্যার জন্য কার্যকর সমাধান নয়, তবে পুরো বাফার এমনকি ছোট ধাক্কা খাওয়ার জন্য বরাদ্দ হওয়ায় মেমরির খরচ উল্লেখযোগ্যভাবে বৃদ্ধি করতে পারে ।

Comments

এটি আমার পক্ষেও কাজ করেছিল, তবে "স্মার্ট এইচটিটিপি ট্রান্সপোর্টস" কখন স্থানান্তরের সাথে জড়িত তা সম্পর্কে আমি কিছুটা বিভ্রান্ত হয়ে পড়েছি ssh://।

— delicateLatticeworkFever

ধন্যবাদ কৌশলটি কাজ করেছে তবে দ্বিগুণ মূল্য সহ এটি উত্তরে দেওয়া হয়েছিল।

— ললিথা রত্নায়াকে

হতে পারে ডকুমেন্টেশনটি ভুল, কিন্তু আপনি HTTP- এ ক্লোন আনার পরে পোস্টটি হয় না। postBufferসেটিংটির ক্লোন বা আনার ক্ষেত্রে কেন কোনও প্রভাব আছে তা নিয়ে আমি বিভ্রান্ত am

— void.pointer

পোস্টবফার উত্থাপন এবং https ব্যবহার আমাকে সাহায্য করে। ধন্যবাদ, ভনসি

— ইয়ুহেন

@ অস্ট্রভ্যাগরান্ট ওকে, মানটি আরও দৃশ্যমান করার জন্য আমি উত্তরটি আপডেট করেছি।

— ভোনসি

Answer 2

বিটবকেটের সাথে একই ত্রুটি। দ্বারা স্থির

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

Comments

এইটি সংযোগ পুনরায় সেট করার ত্রুটি এবং এই ত্রুটিটি নিয়ে আমার সমস্যার সমাধান করেছে: মারাত্মক: দূরবর্তী

— প্রান্তটি

এটা আমার সমস্যা সমাধান! ওম, আমি পুরো ইন্টারনেট দেখেছি, আপনাকে ধন্যবাদ! <3

— সিলভনন

Answer 3

Http.postBuffer কৌতুক করেনি না আমার জন্য হবে। যাহোক:

অন্যরাও এই সমস্যাটি অনুভব করছেন তাদের পক্ষে এটি GnuTLS এর সাথে সমস্যা হতে পারে। আপনি যদি ভারবোজ মোড সেট করে থাকেন তবে নীচের কোডের লাইন ধরে অন্তর্নিহিত ত্রুটি দেখতে পাবেন।

দুর্ভাগ্যক্রমে, এখন পর্যন্ত আমার একমাত্র সমাধান হ'ল এসএসএইচ ব্যবহার করা।

আমি 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

Comments

আমি আপনার মত একই ভার্জোজ লগ পেতে। তবে বৃহত্তর পোস্টবফার মানটি ব্যবহার করে সমাধান করা।

— suiwenfeng

গিট কনফিগারেশন

— suiwenfeng

"HTTP.postbuffer": সীমার বাইরে "মারাত্মক: খারাপ সংখ্যার কনফিগার মান '100000000000000" কারণে নতুন গিট সংস্করণগুলি ব্যর্থ হয়েছে, তবে কনফিগার মানটি সেট করা আমার ক্ষেত্রে সহায়তা করে না।

— কার্ল রিখটার

আমি যে আকারটি অর্জন করতে পারি তা হ'ল100000000000000

— nhoxbypass

Answer 4

ওবস: পরিবর্তনের http.postBufferজন্য ক্লায়েন্ট_ম্যাক্স_বিডি_সাইজের মান টিউন করে গিটল্যাটের বৃহত আকারের দেহের আকারগুলি গ্রহণ করার জন্য গিটল্যাবের জন্য এনগিনেক্স কনফিগারেশন ফাইল সেট আপ করতে হতে পারে।

আপনি Gitlab মেশিন এক্সেস আছে যদি তবে, কার্যসংক্রান্ত নেই বা তার নেটওয়ার্কে মেশিনে, এবং যে ব্যবহার করে হয় git bundle।

1. উত্স মেশিনে আপনার গিট ভাণ্ডারে যান
2. চালান git bundle create my-repo.bundle --all
3. গন্তব্য মেশিনে my-repo.bundle ফাইলটি স্থানান্তর (উদাহরণস্বরূপ, rsync সহ)
4. গন্তব্য মেশিনে, চালান git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

শুভকামনা!

Answer 5

আমার পক্ষে একমাত্র কাজটি ছিল এসএসএইচ লিঙ্কের পরিবর্তে এইচটিটিপিএস লিংকটি ব্যবহার করে রেপো ক্লোন করা ।

Answer 6

আপনি যদি https ব্যবহার করছেন এবং আপনি ত্রুটিটি পাচ্ছেন।

আমি HTTP এর পরিবর্তে https ব্যবহার করেছি এবং এটি আমার সমস্যার সমাধান করে

git config --global https.postBuffer 524288000

Comments

আমার ক্ষেত্রে এটি http.postBuffer এর সাথে কাজ করে নি তাই আপনার পরামর্শ অনুসারে https.postBuffer ব্যবহার করার চেষ্টা করেছি। এই সমাধান কাজ করে। ধন্যবাদ!

— পাসকুট

আমি যদি ssh ব্যবহার করছি? আমি http / https এ যেতে পারি না।

— রবিসনস্টোস

Answer 7

এই উত্তরের ভিত্তিতে , আমি নিম্নলিখিতগুলির চেষ্টা করেছি (https url সহ):

1. রেপোর প্রাথমিক ক্লোনিং:

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সাহায্য করেনি।

ইউপিডি : আমি জানতে পেরেছি যে আপনি এসএসএস কী তৈরি করেছেন, তা দিয়ে ssh এর মাধ্যমে যে কোনও রেপো আকারের (দুর্ঘটনাক্রমে আবিষ্কৃত) কাজ করা যায় for git clone <ssh url>একবার রেপো আনার পরে আমি ব্যবহার করে দূরবর্তী ঠিকানা পরিবর্তন করিgit remote set-url <https url to repo>

Answer 8

নীচের কমান্ডটি ব্যবহার করার পরে আমি সমাধান পেয়েছি:

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

Comments

ক্লোন এখনও স্থানীয় গিট রেপো তৈরি না করে আপনি কীভাবে তা চালিয়ে যাবেন?

— লুসিডব্রোট

Answer 9

আমি একই সমস্যা পেয়েছি, আমি এটি পরীক্ষার এবং ত্রুটি পদ্ধতিতে স্থির করেছি। এটি কাজ না হওয়া পর্যন্ত আমি কোর ডট কম চাপলাম changed

আমি 3 চেষ্টার পরে "গিট কনফিগারেশন - গ্লোবাল কোর ডটকমপ্রেশন 1" দিয়ে শুরু করেছি

"git config --global core.compression 4" আমার পক্ষে কাজ করেছে।

Answer 10

এটি ইন্টারনেট সংযোগ সমস্যার কারণে, আমি একই সমস্যার মুখোমুখি হয়েছি। আমি কোড ব্যবহার করে একটি অগভীর অনুলিপি করেছি

git clone --depth 1 //FORKLOCATION

পরে ক্লোনটি ব্যবহার বন্ধ করে দিয়েছিল

git fetch --unshallow

Answer 11

মধ্যে /etc/resolv.confফাইলের শেষে লাইন যোগ

options single-request

Comments

পোস্টবফার যদি সহায়তা না করে তবে এই উত্তরটি আমার পক্ষে পরবর্তী হিসাবে চেষ্টা করার পরামর্শ দেয়, যা আমার পক্ষে কাজ করেছিল।

— খানহ

Answer 12

ঠিক আছে, আমি একটি 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

সুতরাং গিট 5 এমবি পোস্ট করতে চায়, তারপরে আমি পোস্টটি বাফারটি 6 এমবি করেছি এবং এটি কাজ করে

git config --global http.postBuffer 6291456

Comments

এটি বোঝা যায়। আমি আমার রেপো আকারের দিকে তাকালাম যা 15 এমবি। Ssh এবং এইচটিটিপিএস উভয়ই একই ত্রুটির সাথে অভিযোগ করেছে, এসএসএস কম সহায়ক ছিল। আমি গিথুব থেকে ইস্যু ছাড়াই বড় প্রকল্পগুলি ক্লোন করেছি, এটি একটি বিটবাকেটে ছিল যা কেবল বড় প্রকল্প পছন্দ করে না এবং ডাউনলোড করতে ধীর হয়। গিটল্যাবেও একই জিনিস ঘটে। কিছু সেট করা সমস্যার সমাধান করবে না। এখানে সমস্যা দূরবর্তী নিয়ে। গিথুব এ চলে যাওয়া আমার পোস্টবফারটি আমার রেপো আকারের 15 এম এর কাছাকাছি রেখে আমার মনে হয়েছে, আমি বিশ্বাস করি না এটি এখনও সম্পূর্ণ সমাধান।

— অভিষেক দুজারি

গিট কনফিগারেশন - গ্লোবাল http.postBuffer 157286400, আমি এটি বাফারে সেট করেছিলাম এবং আমার ওয়াইফাইটি পরিবর্তন করে কাজ করেছে।

— ram880

Answer 13

আমার একই সমস্যা ছিল এবং এটি একটি খারাপ ইন্টারনেট সংযোগের সাথে সম্পর্কিত ছিল, তাই কিছু গিট কনফিগারেশনের মাধ্যমে চেষ্টা করার পরে, আমি কেবল আমার নেটওয়ার্ক থেকে সংযোগ বিচ্ছিন্ন করেছি এবং আবার সংযুক্ত হয়েছি এবং এটি কার্যকর হয়!

দেখে মনে হচ্ছে সংযোগটি হারিয়ে যাওয়ার পরে (বা যে ক্রিয়াটি এই পরিস্থিতিকে আগুন ধরিয়ে দেয়), গিট আটকে গেছে।

আমি আশা করি এটি এখানে আরও কারও জন্য সহায়ক হতে পারে।

সেরা

Answer 14

আমারও একই সমস্যা ছিল this এই সমস্যার কারণ জিএনটিএলএস সম্পর্কে কার্টিসের বর্ণনা হিসাবে's

যদি আপনার একই কারণ থাকে এবং আপনার সিস্টেমটি উবুন্টু হয় তবে আপনি গিটের সর্বশেষ সংস্করণটি ইনস্টল করে এই সমস্যাটি সমাধান করতে পারেন ppa:git-core/ppacommands

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

Comments

apt-get git??

— গ্লেন

Answer 15

এডাব্লুএস ইসি 2 ইন ইস্টাস্টিক ইলাস্টিক বিস্টলক দ্বারা পরিচালিত রিমোট গিট রেপো থেকে ডেটা (HTTP এর মাধ্যমে) ক্লোনিং করার সময় আমি এই সমস্যার মুখোমুখি ছিলাম। ক্লোনিং নিজেই এডাব্লুএস ইসি 2 উদাহরণেও করা হয়েছিল।

আমি সমস্ত পূর্বোক্ত সমাধান এবং তাদের সংমিশ্রণ চেষ্টা করেছি:

• গিট এর সেট http.postBuffer
• বিন্যাসhttp.maxrequestbuffer
• গিট সংক্ষেপণ বন্ধ করে এবং "অগভীর" চেষ্টা করে git cloneএবং তারপরে git fetch --unshallow- মারাত্মক দেখুন: প্রারম্ভিক ইওএফ মারাত্মক: সূচক-প্যাক ব্যর্থ হয়েছে
• টিউনিং জিআইটি মেমরি সেটিংস - packedGitLimit এট, এখানে দেখুন: মারাত্মক: প্রারম্ভিক ইওএফ মারাত্মক: সূচক-প্যাক ব্যর্থ হয়েছে
• টিউনিং এনজিনেক্স কনফিগারেশন - client_max_body_sizeউভয় বড় মান এবং 0 (সীমাহীন) এ সেট করা; বিন্যাসproxy_request_buffering off;
• বিন্যাস options single-request/etc/resolv.conf এ করা হচ্ছে
• ট্রিটলিং দিয়ে গিট ক্লায়েন্ট থ্রুপুট thr
• ট্রেসিং জন্য স্ট্রেস ব্যবহার git clone
• গিট ক্লায়েন্ট আপডেট বিবেচনা

এত কিছুর পরেও, আমি এখনও বার বার একই সমস্যার মুখোমুখি হয়েছি , যতক্ষণ না আমি খুঁজে পেয়েছি যে সমস্যাটি সংযোগটি কাটা ইলাস্টিক লোড ব্যালান্সারের (ইএলবি) মধ্যে রয়েছে । ইসি 2 উদাহরণটি অ্যাক্সেস করার পরে (এক হোস্টিং গিট রেপো) সরাসরি ইএলবি দিয়ে না গিয়ে আমি শেষ পর্যন্ত গিট রেপো ক্লোন করতে পেরেছি! আমি এখনও নিশ্চিত নই যে কোনটি ইএলবি (টাইমআউট) প্যারামিটারগুলির জন্য দায়ী, তাই আমাকে এখনও কিছু গবেষণা করতে হবে।

হালনাগাদ

দেখে মনে হচ্ছে যে এডাব্লুএস ইলাস্টিক লোড ব্যালান্সারের জন্য সংযোগ ড্রেনিং নীতি পরিবর্তন করে 20 সেকেন্ড থেকে 300 সেকেন্ডে সময়সীমা বাড়িয়ে আমাদের জন্য এই সমস্যাটি সমাধান করেছে।

git cloneত্রুটি এবং "সংযোগ নিকাশী" এর মধ্যে সম্পর্কটি অদ্ভুত এবং আমাদের কাছে সুস্পষ্ট নয়। এটি হতে পারে যে সংযোগের সময়সীমা পরিবর্তনের ফলে ELB কনফিগারেশনে কিছু অভ্যন্তরীণ পরিবর্তন ঘটেছিল যা অকাল সংযোগ বন্ধ হওয়ার সাথে সাথে সমস্যার সমাধান করে।

এটি এডাব্লুএস ফোরামের সম্পর্কিত প্রশ্ন (এখনও কোনও উত্তর নেই): https://forums.aws.amazon.com/thread.jspa?threadID=258572

Comments

ভাল উত্তর, আমার উত্তর চেয়ে নির্দিষ্ট। +1

— ভোনসি

Answer 16

আমারও একই সমস্যা ছিল, তবে বাঁশের কাজ ছিল। বাঁশগুলি ক্যাশেড সংগ্রহস্থলের স্থানীয় ক্লোন (স্থানীয় তবে একটি এসএসএইচ প্রক্সির ওপরে) করতে ব্যর্থ হয়েছিল, আমি ক্যাশেটি মুছে ফেলেছিলাম এবং তারপরে এটি কাজ করে, তবে যে কোনও সময় এটি স্থানীয় ক্যাশে থেকে ক্লোন করার চেষ্টা করে ব্যর্থ হয়। বাঁশের সংস্করণটি এসএসএইচ প্রক্সির প্রতি গিটের মতো নয় বলে মনে হচ্ছে।

Answer 17

বিটবকেট ব্যবহার করার সময় আমারও একই ত্রুটি রয়েছে। আমি যা করেছি তা ছিল আমার রেপোর URL থেকে https সরিয়ে এবং ইউআরএল ব্যবহার করে সেট করা HTTP।

git remote set-url origin http://[e-mail]/mj/pt.git

Answer 18

ওয়াইফাই রাউটার সেটিং সহ সলভড:

আমি যখন সেটিংস পিপিপিওই (ওয়াইফাই রাউটার দ্বারা অটো লগইন) নিয়ে ওয়াইফাইতে থাকি তখন আমি একই সমস্যা পেয়েছি।

গিট ডাউনলোডের গতি খুব ধীর 15kb।

প্যাকেট_রাইট_উইট: 17.121.133.16 পোর্ট 22 এর সাথে সংযোগ 22: ভাঙা পাইপ মারাত্মক: দূরবর্তী প্রান্তটি অপ্রত্যাশিতভাবে মারাত্মকভাবে ঝুলিয়েছিল: ইওএফ শুরুর দিকে মারাত্মক: সূচক-প্যাক ব্যর্থ হয়েছে

সমাধান: 1. পরিবর্তনশীল সেটিং ডায়নামিক আইপি, রিবুট ওয়াইফাই রাউটারে। ২. ওয়েব ব্রাউজার লগইন থেকে ইন্টারনেট পরিষেবা সরবরাহকারী পোর্টালে (পিপিপিওইই কনফিগার করবেন না, ওয়াইফাই রাউটার থেকে অটো লগইন করুন)।

গিট পরিবর্তন করার পরে ডাউনলোডের গতি হয় 1.7MiB।

Answer 19

এটি আমার সমস্যার সমাধান করেছে:

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

Answer 20

উপরের কৌশলগুলি আমাকে সাহায্য করতে পারেনি, কারণ রেপো গিথুবকে অনুমোদিত সর্বোচ্চ ধাক্কা আকারের চেয়ে বড়। কাজটি কি 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 খুব বেশি হয় এবং আপনি আবার সমস্যাটি আঘাত করেন তবে আপনি সংখ্যাটি সামঞ্জস্য করতে পারেন তাই এটি আরও ছোট।

Comments

আমার 8 বছরের পুরানো উত্তরের আকর্ষণীয় বিকল্প। সম্মত।

— ভোনসি

Answer 21

এই সমাধানগুলির কয়েকটি চেষ্টা করে কয়েক ঘন্টা নষ্ট করলেও শেষ পর্যন্ত এটি একটি কর্পোরেট আইপিএস (ইনস্ট্রিউশন প্রোটেকশন সিস্টেম) -এ সনাক্ত করে নির্দিষ্ট পরিমাণের ডেটা স্থানান্তরিত হওয়ার পরে সংযোগটি ফেলে দেয়।

Answer 22

ভাগ করা ব্যান্ডউইথের জন্য লোড কম হলে ক্লোন করার চেষ্টা করুন। অন্যথায়, একটি উচ্চ গতির সংযোগ দিয়ে চেষ্টা করুন। যদি এখনও কাজ না করে তবে দয়া করে নীচের কমান্ডটি ব্যবহার করুন,

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

এবং আবার ক্লোন করার চেষ্টা করুন। আপনার উপলভ্য মেমরির আকার অনুযায়ী আপনার সেই সেটিংস পরিবর্তন করতে হবে।

Answer 23

এটি সার্ভার সমস্যার মতোই সহজ হতে পারে। যদি গিটহাব ব্যবহার করে থাকেন তবে https://twitter.com/githubstatus দেখুন । আমি এটি এখনই প্রথমবারের মতো দেখেছি এবং গিথহাবের ডাবের ঝাঁকুনি রয়েছে । কয়েক মিনিট পরে এটি আবার ঠিকঠাক কাজ করেছে।

Answer 24

এটি আমার পক্ষে কাজ করেছে, গুগলস নেমসারভার সেট আপ করা হয়েছে কারণ কোনও স্ট্যান্ডার্ড নেমসার্ভার নির্দিষ্ট করা হয়নি, তারপরে নেটওয়ার্কিং পুনরায় চালু করার পরে:

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

Answer 25

কুবুন্টুতে গিট ব্যবহার করে আমি এই সমস্যার মুখোমুখি হয়েছি। আমি নেটওয়ার্কিংয়ে সামগ্রিক অস্থিতিশীলতাও লক্ষ্য করেছি এবং এর সমাধান খুঁজে পেয়েছি ।

/etc/resolv.conf এ ফাইলটির শেষে লাইনটি যুক্ত করুন

বিকল্প একক অনুরোধ

প্রতিটি ডোমেন নেম রেজোলিউশনের আগে এই স্থির বিলম্ব হয় এবং গিট এর পরে কবজির মতো কাজ শুরু করে।

Answer 26

.Netrc ফাইলের সাথে আমার সমস্যাটি খুঁজে পেয়েছি, যদি আপনার পক্ষেও তাই হয় তবে আপনি নিম্নলিখিতটি করতে পারেন:

আপনার .netrc ফাইলটি খুলুন এবং গিথুব শংসাপত্রগুলি অন্তর্ভুক্ত করার জন্য এটি সম্পাদনা করুন। টাইপ nano ~/netrcবাgedit ~/netrc

তারপরে নিম্নলিখিতগুলি অন্তর্ভুক্ত করুন: * মেশিন github.com

লগইন ব্যবহারকারীর নাম

পাসওয়ার্ড সিক্রেট

মেশিন api.github.com

লগইন ব্যবহারকারীর নাম

পাসওয়ার্ড সিক্রেট *

আপনি সেখানে আপনার কাঁচা পাসওয়ার্ড অন্তর্ভুক্ত করতে পারেন তবে সুরক্ষার প্রয়োজনে, এখানে একটি টুথ টুথন তৈরি করতে পারবেন গিথুব টোকেন এবং এটি আপনার পাসওয়ার্ডের জায়গায় আটকে দিন।

আশা করি এটি কাউকে সাহায্য করবে

Answer 27

এটি কমিটের আকারের কারণেই হতে পারে যা ধাক্কা দেওয়া হচ্ছে .. নিম্নলিখিত পদক্ষেপগুলি দ্বারা কমিটের সংখ্যা ভাঙ্গন:

git log -5

শেষ 5 টি কমিটগুলি দেখুন এবং আপনি জানতে পারবেন কোনটি রিমোটে চাপানো হয়নি। একটি প্রতিশ্রুতিবদ্ধ আইডি নির্বাচন করুন এবং সমস্ত আইডিটি আইডি পর্যন্ত চাপ দিন:

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

দ্রষ্টব্য: আমি সবেমাত্র আমার প্রতিশ্রুতি পরীক্ষা করেছি যা সবচেয়ে বড় আকার হতে পারে; প্রথম পর্যন্ত ততক্ষণ পর্যন্ত ধাক্কা। কৌতুক কাজ করেছে। !!

Answer 28

আমি আমার ওএস এক্স এল ক্যাপিটান ম্যাক থেকে গিট পুশ করছিলাম। আমি একই ত্রুটি পাচ্ছিলাম, আমি গুগল / স্ট্যাকওভারফ্লোতে যা পেয়েছি তা ঠিক করার জন্য সবকিছু চেষ্টা করেছি। যতক্ষণ সংস্করণ সম্পর্কিত, আমি গিথুবের মোটামুটি সর্বশেষ সংস্করণটি ব্যবহার করছি যা 2.7.4 .4 আমি আমার স্থানীয় সিস্টেমে একটি প্রকল্প তৈরি করেছি এবং আমি চাইছিলাম এটি আমার গিথুব অ্যাকাউন্টে সর্বজনীন হোক। প্রকল্পের আকার 8MB এর কাছাকাছি ছিল না। আমি লক্ষ্য করেছি যে যখন আমি 1.5MB এর কাছাকাছি আকারের কিছু ফাইল চাপছি তখন এটি সঠিকভাবে চাপ দিচ্ছিল, তবে একই ত্রুটির সাথে আমার পক্ষে বড় আকারের ব্যর্থ হয়েছে,

আমার কাছে কেবলমাত্র বিকল্প ছিল এমবি-র পরিবর্তনের পরিবর্তনগুলি push এখন আমি সমস্ত পরিবর্তন ঠেলেছি। আমি এই সমাধানটির সমাধান না পাওয়া পর্যন্ত এটি আমার পক্ষে কার্যকর নয়।

সুতরাং আপনি একাধিক প্রতিশ্রুতি পরিবর্তনের জন্য চেষ্টা করতে পারেন। অথবা আপনার যদি একাধিক ফোল্ডার থাকে তবে আপনি প্রতিটি ফোল্ডার দ্বারা পরিবর্তনগুলি ধাক্কা দিতে পারেন (যদি ফোল্ডারের আকার বড় না হয়)।

আশা করি এটি আপনাকে প্রকল্পে অবিচ্ছিন্নভাবে কাজ করতে সহায়তা করবে।

Answer 29

একই সমস্যার মুখোমুখি, অন্য একটি শাখায় মার্জ করার চেষ্টা করুন এবং সেগুলি থেকে টানুন। এটা আমার জন্য একই কাজ করে।

Answer 30

sshপরিবর্তে ব্যবহার করুন http, এটি এই প্রশ্নের পক্ষে ভাল উত্তর নয় তবে কমপক্ষে এটি আমার পক্ষে কাজ করে