মারাত্মক: প্রারম্ভিক EOF মারাত্মক: সূচক-প্যাক ব্যর্থ


271

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

ল্যান নেটওয়ার্কে থাকা রিমোট সার্ভারের সাথে সংযোগ স্থাপন করে আমি একটি মেশিন থেকে ক্লোন করার চেষ্টা করছি।
অন্য মেশিন থেকে এই কমান্ডটি চালানো ত্রুটির কারণ ঘটায় cause
কিন্তু গিট: //192.168.8.5 ব্যবহার করে Same ক্লোন কমান্ড চালাচ্ছে ... সার্ভারে এটি ঠিক আছে এবং সফল।

কোন ধারনা ?

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তবে কোনও সহায়তাও নেই।
গিট সংস্করণটি 1.8.5.2.msysgit.0 ব্যবহার করে

[core]
    compression = -1

8
আমি যখন ভিপিএন থেকে ক্লোন করার চেষ্টা করছিলাম তখন আমি 2-3 দিনের জন্য এই সমস্যার মুখোমুখি হয়েছিলাম। আমার ক্ষেত্রে ইস্যুটি ছিল নেটওয়ার্ক ব্যান্ডউইথ। আমি হাই স্পিড নেটওয়ার্কে ক্লোনিং করে ঠিক করেছি।
অভিজিৎ নাগারে

1
আমি এটি নেটওয়ার্ক-সম্পর্কিতও লক্ষ্য করেছি।
আশ্চর্য

1
আমি এই ত্রুটিটি পেয়েছি কারণ আমার বন্ধুরা গিটটি এতটা ভাল জানেন না এবং প্রচুর চিত্রগুলি সংগ্রহস্থলটিতে ঠেলাচ্ছেন! =))
ক্লাইট টেইলর

আমি এটি নেটওয়ার্ক-সম্পর্কিতও লক্ষ্য করেছি। আমি হাই স্পিড নেটওয়ার্কে ক্লোনিং করেও ঠিক করেছি।
shashaDenovo

উত্তর:


505

প্রথমে সংক্ষেপণ বন্ধ করুন:

git config --global core.compression 0

এর পরে, আসুন তথ্যের পরিমাণ কমিয়ে দেওয়ার জন্য আংশিক ক্লোনটি করা যাক:

git clone --depth 1 <repo_URI>

যখন এটি কাজ করে, নতুন ডিরেক্টরিতে যান এবং ক্লোনটির বাকী অংশটি পুনরুদ্ধার করুন:

git fetch --unshallow 

বা, পর্যায়ক্রমে,

git fetch --depth=2147483647

এখন, নিয়মিত টান দিন:

git pull --all

আমি মনে করি যে 1.8.x সংস্করণে এমএসজিগিটের সাথে একটি গণ্ডগোল রয়েছে যা এই লক্ষণগুলিকে আরও বাড়িয়ে তোলে, তাই অন্য বিকল্পটি গিটের পূর্ববর্তী সংস্করণ দিয়ে চেষ্টা করা উচিত (<= 1.8.3, আমি মনে করি)।


6
আপনাকে ধন্যবাদ, এটি দুর্দান্ত কাজ করেছে। আমি http.postbuffer পরিবর্তন করার চেষ্টা করেছি যা কাজ করে না, তবে এই উত্তরে বর্ণিত হিসাবে কাজ করার পরে এটি দুর্দান্ত কাজ করেছে। আমি "গিট ফেচ --depth = 2147483647" লাইনটি ব্যবহার করি নি, তবে আমি বাকীটি ব্যবহার করেছি।
নিক বেনেডিক্ট

2
@ ইথেনা.উইলসন আপনার পরে সংগ্রহস্থলের জন্য রিমোট url এ যেতে হবে pass যেমন git clone --depth 1 git@host:user/my_project.git
নাথন গোল্ড

6
@ জোস এ। - আমি যখন এমএসজিগিতের নতুন সংস্করণে ছিলাম তখন আমি এই সমস্যাটি অনুভব করেছি। আপনি যদি এমএসজিগিতে থাকেন তবে পুরানো সংস্করণটি ব্যবহার করে দেখুন (<= 1.8.3)। অন্যথায়, গিট আনার চেষ্টা করুন - 1000 ডাইপথ (তারপরে 2000 ইত্যাদি, সমস্ত ফাইল টান না হওয়া পর্যন্ত ক্রমবর্ধমান বৃদ্ধি)।
ইনজিহেইর করুন

2
: - @Jose উ: এছাড়াও, এই একটি চেহারা আছে stackoverflow.com/questions/4826639/...
ingyhere

2
হাই প্রিয় বন্ধু. আপনার দুর্দান্ত সমাধানের জন্য আপনাকে ধন্যবাদ। কিন্তু শেষের git pull --allকাজ করে না। কারণ git clone --depth 1মাত্র একটি শাখা আনার পরিসীমা সেট করবে। সুতরাং আমাদের প্রথমে .git / কনফিগার করতে হবে।
pjincz

93

এই ত্রুটি গিটের মেমরির প্রয়োজনে ঘটতে পারে। তুমি তোমার বিশ্বব্যাপী Git কনফিগারেশন ফাইল, যা থেকে এই লাইন যোগ করতে পারেন .gitconfigমধ্যে $USER_HOMEযাতে সমস্যাটি সমাধানের জন্য যে।

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

এটি আমার পক্ষে কাজ করেছিল - যদিও আমার এখনও বেশ কয়েকটি প্রচেষ্টা দরকার ছিল, তবে এই পরিবর্তন ছাড়াই বন্ধ হওয়াটি 30% এ এসেছিল, পরে 75% এ ... এবং একবার এটি 100% এ গিয়ে কাজ করে। :)
peschü

অবশ্যই নির্বাচিত উত্তর হতে হবে
অসীম কাসেমজাদে

উইন্ডোগুলিতে, 2.9 গিট সহ এটি এটি স্থির করে। বিশেষত প্যাক সম্পর্কিত প্যারাম যুক্ত করা।
20rτhικ

কাজ করছে! ধন্যবাদ!
গিলি অ্যাকোস্টা

এখনও আমার পক্ষে কাজ করছে না remote: Enumerating objects: 43, done. remote: Counting objects: 100% (43/43), done. remote: Compressing objects: 100% (24/24), done. error: inflate returned -55/26) fatal: unpack-objects failed
জীবন চৈতন্য

26

অবশেষে সমাধান git config --global core.compression 9

একটি বিটবাকেট ইস্যু থ্রেড থেকে:

আমি প্রায় পাঁচবার চেষ্টা করেছি, এবং এখনও তা ঘটে।

তারপরে আমি আরও ভাল কম্প্রেশন ব্যবহার করার চেষ্টা করেছি এবং এটি কাজ করেছে!

git config --global core.compression 9

গিট ডকুমেন্টেশন থেকে:

core.compression
একটি পূর্ণসংখ্যা -1..9, একটি ডিফল্ট সংকোচনের স্তর নির্দেশ করে। -1 হল zlib ডিফল্ট।
0 এর অর্থ হ'ল কোনও সংকোচনের নয় এবং 1..9 হ'ল বিভিন্ন গতি / আকারের ট্রেড অফস, 9 ধীরে ধীরে।
যদি সেট করা থাকে তবে এটি অন্য সংক্ষেপণের ভেরিয়েবলগুলিকে ডিফল্ট সরবরাহ করে যেমন কোর.লোজকম্প্রেশন এবং প্যাক ডট কম।


3
git repackএই সমাধানটির সাথে একত্রে চালানো দরকার এবং তারপরে এটি কার্যকর হয়েছিল।
এরিক এইচ

এটি কাজ করেছে, এমনকি অন্যান্য সমাধানও চেষ্টা করে দেখেনি কারণ এটি হ'ল সংক্ষিপ্ততম এবং সবচেয়ে মার্জিত। উত্তর গ্রহণ করা উচিত!
মেটাব্লাস্টার

এটি ভিপিএন এবং কর্পোরেট প্রক্সি হয়ে আমার পক্ষেও কাজ করে। উপরে বর্ণিত --compression 0সমস্ত .gitconfigপরিবর্তন কার্যকর হয়নি ।
টেরেন্স ব্র্যানন

20

যেমনটি ইঙ্গিত এখানে বলেছেন:

অগভীর ক্লোন

প্রথমে সংক্ষেপণ বন্ধ করুন:

git config --global core.compression 0

এর পরে, আসুন তথ্যের পরিমাণ কমিয়ে দেওয়ার জন্য আংশিক ক্লোনটি করা যাক:

git clone --depth 1 <repo_URI>

যখন এটি কাজ করে, নতুন ডিরেক্টরিতে যান এবং ক্লোনটির বাকী অংশটি পুনরুদ্ধার করুন:

git fetch --unshallow

বা, পর্যায়ক্রমে,

git fetch --depth=2147483647

এখন, একটি টানুন:

git pull --all

তারপরে আপনার স্থানীয় শাখার সমস্যা সমাধানের জন্য কেবল ট্র্যাকিংয়ের মাস্টার

.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/*

একটি গিট আনুন এবং গিট এখন আপনার সমস্ত দূরবর্তী শাখা টানবে


এটি কাজ করে, তবে আমি 9 টি নয় 0 তে সংকোচন রেখেছি যা ব্যর্থ হয়েছিল।
মেটাব্লাস্টার

9

আমার ক্ষেত্রে এটি বেশ সহায়ক ছিল:

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

এটি চেকআউটকে কেবলমাত্র উল্লিখিত শাখায় সীমাবদ্ধ করবে, সুতরাং প্রক্রিয়াটি গতি বাড়িয়ে তুলবে।

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


6

আমি এই সমস্ত কমান্ড চেষ্টা করেছিলাম এবং আমার পক্ষে কেউ কাজ করে না, তবে কী কাজ করে তা git_url টি এইচটি পরিবর্তে পরিবর্তিত করে ssh করে দেওয়া হয়েছিল

যদি ক্লোন কমান্ড হয়:

git clone <your_http_or_https_repo_url> 

অন্যথায় যদি আপনি বিদ্যমান রেপো টানছেন তবে এটি দিয়ে করুন

git remote set-url origin <your_http_or_https_repo_url>

আশা করি এই সাহায্য কারও!


1
এই প্রশ্নটি আসলে উপরের আউটপুটটিতে ত্রুটি বার্তা সম্পর্কে যখন কোনও সংযুক্ত রেপো থেকে ফাইলের বিশাল অংশগুলি সিঙ্ক করতে সমস্যা হয়। আপনি বলছেন যে এসএসএস থেকে https এ কাটা ক্লোনটি শেষ করার অনুমতি দিয়েছে?
ingyhere

হ্যাঁ! আমার পক্ষে সেই কাজ, আমার কাছে একটি 4 জিবি + রেপো রয়েছে এবং আমি যে কাজটি পেয়েছিলাম তার একমাত্র সমাধান ছিল তা!
elin3t

2
এটি আমার জন্য কাজ করে, আপনাকে ধন্যবাদ! দ্বারা ক্লোন করুন httpsএবং তারপরে রিমোটটি আবার সেট করুন ssh
তুয়ান

1
কেন এটি কাজ করেছে তা আমি সত্যিই জানতে চাই । এসএসএইচ প্রোটোকলে এমন কি এমন কিছু আছে যা এইচটিটিপিএস না করে এমন বড় অবজেক্টগুলিকে চোক করে? এটি কি পরিবহন স্তরের সমস্যা?
বিডেটওয়েলার

6

গিটটি স্মৃতিশক্তি শেষ হয়ে যাওয়ার পরে আমি এই ত্রুটিটি পেয়েছি।

কিছু স্মৃতি মুক্ত করা (এক্ষেত্রে: একটি সংকলন কাজ শেষ করে দেওয়া) এবং আমার জন্য আবার চেষ্টা করার চেষ্টা করা।


আমার জন্য, খুব বেশি স্মৃতি উপলব্ধ ছিল না, কিছু মুক্ত করে এটিকে পুনরায় চেষ্টা করার সমাধান হয়েছে।
মার্টিন ক্যাসিডি

4

আমার ক্ষেত্রে এটি একটি সংযোগ সমস্যা ছিল। আমি একটি অভ্যন্তরীণ ওয়াইফাই নেটওয়ার্কের সাথে সংযুক্ত ছিলাম, যেখানে আমার রিসোর্সের সীমাবদ্ধ অ্যাক্সেস ছিল। এটি গিটকে আনতে দিচ্ছিল তবে একটি নির্দিষ্ট সময়ে এটি ক্র্যাশ হয়েছিল। এর অর্থ এটি একটি নেটওয়ার্ক-সংযোগ সমস্যা হতে পারে। সবকিছু ঠিকঠাক চলছে কিনা তা পরীক্ষা করুন: অ্যান্টিভাইরাস, ফায়ারওয়াল ইত্যাদি

এলিন 3 টি এর উত্তর তাই গুরুত্বপূর্ণ কারণ এসএসএস ডাউনলোডের কার্যকারিতা উন্নত করে যাতে নেটওয়ার্কের সমস্যাগুলি এড়ানো যায়


4

নীচের কনফিগারেশন সেট করা আমার পক্ষে কাজ করে না।

[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

2

পূর্ববর্তী উত্তরটি 512 মি তে সেট করার পরামর্শ দেয়। আমি বলব যে bit৪ বিটের আর্কিটেকচারে এমনটি ভাবার কারণ রয়েছে। Core.packedGitLimit ডকুমেন্টেশন বলেছেন:

ডিফল্ট 32 বিট প্ল্যাটফর্মের 256 মাইবি এবং 64 টি বিট প্ল্যাটফর্মগুলিতে 32 টিআইবি (কার্যকরভাবে সীমাহীন)। এটি বৃহত্তম ব্যবহারকারী ব্যতীত সমস্ত ব্যবহারকারী / অপারেটিং সিস্টেমের পক্ষে যুক্তিসঙ্গত হওয়া উচিত। আপনার সম্ভবত এই মানটি সামঞ্জস্য করার দরকার নেই।

আপনি যদি এটি চেষ্টা করে দেখতে চান তবে এটি সেট আছে কিনা তা পরীক্ষা করে দেখুন এবং তারপরে সেটিংসটি সরিয়ে ফেলুন:

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

1

নোট করুন যে গিট 2.13.x / 2.14 (Q3 2017) ডিফল্টটিকে core.packedGitLimitপ্রভাবিত করে যা প্রভাবিত করে git fetch: একটি "পুনরুদ্ধারযোগ্য" ব্যর্থতা থেকে " " বাঁচানোর জন্য
ডিফল্ট প্যাকড-গিট সীমা মান বড় প্ল্যাটফর্মগুলিতে ( 8 GiB থেকে 32 GiB ) উত্থাপিত হয় git fetchযেখানে " gc" সমান্তরাল চলমান হয়।

দেখুন কমিট be4ca29 (20 এপ্রিল 2017) দ্বারা ডেভিড টার্নার ( csusbdt)
সহায়তা করেছেন: জেফ কিং ( peff)
(দ্বারা একীভূত junio সি Hamano - gitster- মধ্যে d97141b কমিট , 16 মে 2017)

বৃদ্ধি core.packedGitLimit

যখন core.packedGitLimitঅতিক্রম করা হবে, গিট প্যাকগুলি বন্ধ করবে।
যদি আনার সাথে সমান্তরালে কোনও পুনরায় ক্রিয়াকলাপ চলছে, তবে আনতে প্যাকটি খুলতে পারে এবং প্যাকড গিটলিমিট আঘাত হানার কারণে এটি বন্ধ করতে বাধ্য হতে পারে।
পুনঃস্থাপনটি তখন আনতে পারে যাতে আনতে পারে না, ফলে আনতে ব্যর্থ হয়।

বৃদ্ধি core.packedGitLimitএটি রোধ করতে এর ডিফল্ট মান ।

বর্তমান -৪-বিট x86_64 মেশিনে, ঠিকানার জায়গার 48 বিট উপলব্ধ।
দেখা যাচ্ছে যে 64-বিট এআরএম মেশিনগুলির কোনও ঠিকানার জায়গার মান নেই (এটি নির্মাতার দ্বারা পৃথক হয়), এবং আইএ 64 এবং পাওয়ার মেশিনগুলিতে পূর্ণ 64 বিট রয়েছে।
সুতরাং 48 বিট একমাত্র সীমা যা আমরা যুক্তিসঙ্গতভাবে যত্ন নিতে পারি can আমরা কার্নেলের ব্যবহারের জন্য 48-বিট ঠিকানা জায়গার কয়েকটি বিট সংরক্ষণ করি (এটি কঠোরভাবে প্রয়োজনীয় নয়, তবে এটি নিরাপদ থাকা ভাল) এবং অবশিষ্ট 45 টি পর্যন্ত ব্যবহার করুন
any কোনও গিট রিপোজিটরি এই বৃহতের কাছাকাছি কোথাও থাকবে না শীঘ্রই, সুতরাং এটি ব্যর্থতা প্রতিরোধ করা উচিত।


1

@Cmpickle উত্তর ব্যবহার করে, আমি ক্লোন প্রক্রিয়া সহজ করার জন্য একটি স্ক্রিপ্ট তৈরি করেছি।

এটি এখানে হোস্ট করা হয়: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

আপনি নিম্নলিখিত লাইনটি ব্যবহার করে এটি চালাতে পারেন:

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

1

আমার ক্ষেত্রে সমস্যাটি গিট কনফিগারেশন প্যারামিটারগুলির মধ্যে কোনওটিই ছিল না তবে এই সত্যটি যে আমার সংগ্রহস্থলে আমার সিস্টেমে অনুমোদিত ফাইলের আকারের চেয়ে বেশি একটি ফাইল ছিল। আমি এটি একটি বড় ফাইল ডাউনলোড করার চেষ্টা করে এবং ডেবিয়ানে একটি "ফাইলের আকার সীমা অতিক্রম" পেয়েছি তা পরীক্ষা করতে সক্ষম হয়েছি।

এর পরে আমি আমার /etc/security/limits.conf ফাইলটি সম্পাদনা করেছি এবং এর শেষে নিম্নলিখিত লাইনগুলি যুক্ত করছি: * হার্ড fsize 1000000 * নরম fsize 1000000

নতুন সীমা মানগুলি আসলে "প্রয়োগ" করতে আপনাকে পুনরায় লগইন করতে হবে


1

স্পর্শকাতরভাবে সম্পর্কিত এবং শুধুমাত্র আপনার যদি কোনও রুট অ্যাক্সেস না থাকে এবং কোনও আরপিএম (rpm2cpio সহ) অথবা অন্য প্যাকেজ (.deb, ..) থেকে সাবফোল্ডারটিতে গিটটি ম্যানুয়ালি বের করতে পারে তবে কেবলমাত্র কার্যকর। সাধারণ ব্যবহারের ক্ষেত্রে: আপনি কর্পোরেট সার্ভারে পুরানো সংস্করণে গিটের একটি নতুন সংস্করণ ব্যবহার করার চেষ্টা করছেন।

যদি গিট ক্লোনটি প্রারম্ভিক ইওএফ উল্লেখ fatal: index-pack failed ছাড়াই ব্যর্থ হয় তবে পরিবর্তে একটি সহায়তা বার্তা সম্পর্কে উল্লেখ করা হয় তবে usage: git index-packএকটি সংস্করণ মিলছে না এবং আপনাকে --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

1

Ssh এর উপর গিট (v2.17.1) ব্যবহার করে আমার একই ত্রুটিযুক্ত লগ ছিল। আমার ক্ষেত্রে সমাধানটি হ'ল:

  1. আমার সার্ভারের গিট বেয়ার স্টোরেজে প্রবেশ করুন।
  2. কল 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 push সমস্যা ।


অন্যান্য (হ্যাক) সমাধান ইতিহাস ছাড়াই শেষ মাস্টার ডাউনলোড করছে:

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

এমন সম্ভাবনা রয়েছে যে বাফার ওভারফ্লো হবে না।


0

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

গিট ক্লোন - ডেপথ 1 "এসএসএস: .জিট" - ব্রাঞ্চ "নির্দিষ্ট_ব্রঞ্চ"


0

এর মধ্যে আমি যে সমস্ত ডাউনলোডগুলি করছিলাম তা আমি বন্ধ করে দিয়েছি, যা সম্ভবত কিছু জায়গা ছেড়ে দিয়েছে এবং ব্যান্ডউইথ পরিষ্কার করেছে


0

গিট-ডেমন ইস্যুটি v2.17.0 এ সমাধান করা হয়েছে বলে মনে হয়েছে (একটি কর্মহীন v2.16.2.1 দ্বারা যাচাই করা হয়েছে )। অর্থাৎ "লক আউটপুট বাফার" তে কনসোলে পাঠ্য নির্বাচনের কাজটির আর প্রয়োজন হবে না।

Https://github.com/git/git/blob/v2.17.0/ ডকুমেন্টেশন / রেলনোটস / 2.17.0.txt থেকে :

  • "গিট ডিমন" - এ সংশোধিত ফিক্সগুলি। (ed15e58efe জে কে / ডেমন-ফিক্সগুলি পরে রক্ষণাবেক্ষণে মার্জ করুন)।

0

আমি একই সমস্যা আছে। উপরের প্রথম ধাপ অনুসরণ করে আমি ক্লোন করতে সক্ষম হয়েছি, তবে আমি আর কিছুই করতে পারি না। পুরানো শাখাগুলি আনতে, টানতে বা চেকআউট করতে পারে না।

প্রতিটি কমান্ড স্বাভাবিকের চেয়ে অনেক ধীর গতিতে চলতে থাকে, তারপরে বস্তুগুলি সংকুচিত করার পরে মারা যায়।

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 টি সম্পাদনা রয়েছে। এর পরে, আপনি যে কোনও কমান্ড ঠিকঠাক এবং স্বাভাবিক গতিতে করতে পারেন।


আপনি টেড বলতে কি বোঝাতে চান?
বিশ্ব প্রেমলাল

এই "উত্তর" এর উত্তরটি এখানে উত্তর দেওয়া উচিত ছিল '
mc0e

0

এখানে বেশিরভাগ উত্তর চেষ্টা করে দেখেছি, আমি PTTY SSH ক্লায়েন্টের সাথে সমস্ত সম্ভাব্য নক্ষত্রের সাথে ত্রুটি পেয়েছি ।

আমি ওপেনএসএসএইচে স্যুইচ করলে একবার ত্রুটিটি চলে যায় (এনভায়রনমেন্ট ভেরিয়েবল GIT_SSH সরান এবং গিট ব্যাশ পুনরায় চালু করুন)।

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


0

আমি একই সমস্যা অভিজ্ঞতা পেয়েছি। আরপিও এসএসএইচ এর মাধ্যমে ডাউনলোড করা খুব বড় ছিল। @ এলিন 3 টি প্রস্তাবিত ঠিক যেমন, আমি এইচটিটিপি / এইচটিটিপিএসের উপরে ক্লোন করেছি এবং এসএসএইচ আরপিও ব্যবহার করতে .git / কনফিগারেশনে রিমোট URL টি পরিবর্তন করেছি ।


0

আমি চালানোর সময় নীচের মত একই সমস্যা পেয়েছি 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, অনেক অনিচ্ছাকৃত পরিবর্তন হয়েছিল আমি প্রতিশ্রুতিবদ্ধ হয়ে সমস্ত সংশোধিত পরিবর্তনগুলিকে চাপ দিয়ে সমস্যার সমাধান করেছি ।


0

উপরের কোনও সমাধানই আমার পক্ষে কাজ করেনি।

অবশেষে আমার জন্য যে সমাধানটি কাজ করেছিল তা হ'ল এসএসএইচ ক্লায়েন্টটি পরিবর্তন করা। GIT_SSH এনভায়রনমেন্ট ভেরিয়েবলটি উইন্ডোজ সার্ভার 2019 সরবরাহিত ওপেনএসএসএইচে সেট করা হয়েছিল Version সংস্করণ 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


0

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

এটি গিট দ্বারা ব্যবহৃত ssh এর সংস্করণ হিসাবে শেষ হয়েছিল। গিটটি ওপেন এসএসএইচ-এর কয়েকটি সংস্করণ ব্যবহার করার জন্য কনফিগার করা হয়েছিল, ব্যবহারকারীরা। Gitconfig ফাইলটিতে कोर.এসএসকম কম্যান্ড ভেরিয়েবলের মাধ্যমে উল্লেখ করেছেন। সেই লাইনটি সরিয়ে ফেলা এটি ঠিক করে দিয়েছে। আমি বিশ্বাস করি এটি কারণ উইন্ডোজ এখন এসএসএইচের একটি আরও নির্ভরযোগ্য / সামঞ্জস্যপূর্ণ সংস্করণ সহ প্রেরণ করে যা ডিফল্টরূপে ব্যবহৃত হয়।


-1

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

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

-1

গিট ক্লোন থেকে, আমি পেয়েছিলাম:

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

আমার মেশিনটি রিবুট করার পরে, আমি রেপো ফাইনকে ক্লোন করতে সক্ষম হয়েছি।


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

-1

আপনি যদি উইন্ডোজে থাকেন, আপনি "ইনডেক্স-প্যাক" ব্যর্থ হয়ে গিট ক্লোন ব্যর্থ হয়েছে তা পরীক্ষা করতে চাইতে পারেন ?

মূলত, আপনার চালানোর পরে git.exe daemon ... কমান্ড , সেই কনসোল উইন্ডো থেকে কিছু পাঠ্য নির্বাচন করুন। পুনরায় টানতে / ক্লোনিং করার চেষ্টা করুন, এটি এখনই কাজ করতে পারে!

আরও তথ্যের জন্য এই উত্তর দেখুন ।



-3

এগুলির কোনওটিই আমার পক্ষে কাজ করেনি, তবে হেরোকুর বিল্ট ইন টুল ব্যবহার করে কৌশলটি সফল হয়নি।

heroku git:clone -a myapp

ডকুমেন্টেশন এখানে: https://devcenter.heroku.com/articles/git-clone-heroku-app

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.