घातक: प्रारंभिक EOF घातक: सूचकांक-पैक विफल

271

मैंने गुगली की है और कई समाधान पाए हैं लेकिन कोई भी मेरे लिए काम नहीं करता है।

मैं एक सर्वर से क्लोन करने की कोशिश कर रहा हूं जो दूरस्थ नेटवर्क में है जो LAN नेटवर्क में है।
किसी अन्य मशीन से इस कमांड को चलाने में त्रुटि होती है।
लेकिन git: //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लेकिन इसमें भी कोई मदद नहीं मिली है।
Git संस्करण 1.8.5.2.msysgit.0 का उपयोग करना

[core]
    compression = -1

git cygwin msysgit

— विलियम
स्रोत

8

जब मैं वीपीएन से क्लोन करने की कोशिश कर रहा था तो मुझे 2-3 दिनों के लिए इस मुद्दे का सामना करना पड़ा। मेरे मामले में नेटवर्क बैंडविड्थ था। मैं उच्च गति नेटवर्क में क्लोनिंग द्वारा तय की।

— अविजित नागरे 8

1

मैंने यह भी देखा है कि यह नेटवर्क से संबंधित है।

— आश्चर्य

1

मुझे यह त्रुटि मिली क्योंकि मेरे दोस्त इतनी अच्छी तरह से नहीं जानते हैं और बहुत सारी छवियों को भंडार में धकेल देते हैं! =))

— क्लिट टेलर

मैंने यह भी देखा है कि यह नेटवर्क से संबंधित है। मैं भी उच्च गति नेटवर्क में क्लोनिंग द्वारा तय की।

— shashaDenovo

506

सबसे पहले, संपीड़न बंद करें:

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 संस्करणों में msysgit के साथ एक गड़बड़ है जो इन लक्षणों को बढ़ाता है, इसलिए एक और विकल्प git के पुराने संस्करण (<= 1.8.3, मुझे लगता है) के साथ प्रयास करना है।

— ingyhere
स्रोत

6

धन्यवाद, इस महान काम किया। मैंने http.postbuffer को बदलने की कोशिश की थी, जो काम नहीं आया, लेकिन इस उत्तर में कहा गया काम करने के बाद, इसने बहुत अच्छा काम किया। मैंने "git fetch --depth = 2147483647" लाइन का उपयोग नहीं किया, लेकिन मैंने बाकी का उपयोग किया।

— निक बेनेडिक्ट

2

@ EthenA.Wilson आपको बाद में रिपॉजिटरी के लिए रिमोट यूआरएल में पास करना होगा। जैसे git clone --depth 1 git@host:user/my_project.git।

— नाथन गोल्ड

6

@ जोसे ए - मुझे इस समस्या का अनुभव तब हुआ जब मैं msysgit के एक नए संस्करण पर था। यदि आप msysgit पर हैं, तो एक पुराना संस्करण (<= 1.8.3) आज़माएं। अन्यथा, git लाने की कोशिश करें - ddepth 1000 (तब 2000 इत्यादि), जब तक कि सभी फाइलें खींच न ली जाएं तब तक बढ़ाना।

— चलो

2

@ जोस ए - इसके अलावा, इस पर एक नज़र डालें: stackoverflow.com/questions/4826639/…

— ingyhere

2

नमस्ते प्यारे मित्र। आपके महान समाधान के लिए धन्यवाद। लेकिन आखिरी git pull --allकाम नहीं करता। क्योंकि git clone --depth 1केवल एक शाखा के लिए सीमा तय की जाएगी। इसलिए हमें पहले .git / config को एडिट करना होगा।

— पंकज जूल

93

यह त्रुटि मेमोरी की आवश्यकता के लिए हो सकती है। आप इन पंक्तियों को अपनी वैश्विक git कॉन्फ़िगरेशन फ़ाइल में जोड़ सकते हैं, जो है.gitconfig में $USER_HOMEआदेश है कि इस समस्या को ठीक करने के लिए,।

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

— bhdrkn
स्रोत

इसने मेरे लिए काम किया - हालाँकि मुझे अभी भी कई प्रयासों की आवश्यकता थी, लेकिन इस बदलाव के बिना गर्भपात 30%, बाद में 75% और ... एक बार 100% हो गया और काम किया। :)

— peschü

चयनित उत्तर होना चाहिए

— असीम क़ासमज़ादे

विंडोज़ पर, 2.19 git के साथ, इसने इसे ठीक किया। विशेष रूप से पैक से संबंधित परमेस को जोड़ना।

— 18αrΚ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

— जीवन चैतन्य 19 ’

26

अंत में हल कर दिया 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 को एक डिफ़ॉल्ट प्रदान करता है।

— जैकी
स्रोत

3

git repackइस समाधान के साथ संयोजन में चलाने की आवश्यकता है और फिर इसने काम किया।

— इरिक

यह काम किया, अन्य समाधानों की भी कोशिश नहीं की क्योंकि यह सबसे छोटा और सबसे सुरुचिपूर्ण है। उत्तर स्वीकार किया जाना चाहिए!

— मेटालैस्टर

यह मेरे लिए भी वीपीएन और कॉर्पोरेट प्रॉक्सी के माध्यम से काम करता है। --compression 0काम नहीं किया और न ही .gitconfigऊपर उल्लिखित सभी बदलाव किए गए।

— टेरेंस ब्रैनोन

20

जैसा कि @ingyhere ने कहा:

उथला क्लोन

सबसे पहले, संपीड़न बंद करें:

git config --global core.compression 0

अगला, आइए नीचे आने वाली जानकारी की मात्रा को कम करने के लिए एक आंशिक क्लोन करें:

git clone --depth 1 <repo_URI>

जब वह काम करता है, तो नई निर्देशिका में जाएं और शेष क्लोन को पुनः प्राप्त करें:

git fetch --unshallow

या, बारी-बारी से,

git fetch --depth=2147483647

अब, एक पुल करें:

git pull --all

फिर अपनी स्थानीय शाखा की समस्या को हल करने के लिए केवल ट्रैकिंग मास्टर

अपनी git config फाइल खोलें (.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 अब आपकी सभी दूरस्थ शाखाओं को खींच लेगा

— cmpickle
स्रोत

यह काम करता है, लेकिन मैंने 9 नहीं 0 को संपीड़न छोड़ दिया जो विफल रहा।

— मेटाबलास्टर

9

मेरे मामले में यह काफी मददगार था:

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

यह चेकआउट को केवल उल्लिखित शाखा तक सीमित करेगा, इसलिए इस प्रक्रिया को गति देगा।

आशा है कि यह मदद करेगा।

— sMajeed
स्रोत

6

मैंने उस सभी कमांड की कोशिश की और कोई भी मेरे लिए काम नहीं करता है, लेकिन क्या काम करता है git_url को http के बजाय ssh

अगर क्लोन कमांड है:

git clone <your_http_or_https_repo_url>

और यदि आप मौजूदा रेपो पर खींच रहे हैं, तो इसके साथ करें

git remote set-url origin <your_http_or_https_repo_url>

उम्मीद है कि यह किसी की मदद करो!

— elin3t
स्रोत

1

यह सवाल वास्तव में ऊपर के आउटपुट में त्रुटि संदेश के बारे में है जब एक जुड़े हुए रेपो से फाइलों के विशाल विखंडू को समकालने में समस्या होती है। आप कह रहे हैं कि ssh से https को काटकर क्लोन को समाप्त करने की अनुमति दी गई है?

— ingyhere

हाँ! मेरे लिए वह काम, मेरे पास एक 4gb + रेपो है और केवल एक ही समाधान मुझे मिला वह काम था!

— elin3t

2

यह मेरे लिए काम करता है, धन्यवाद! द्वारा क्लोन किया गया httpsऔर फिर रिमोट को वापस सेट किया गया ssh।

— तुआन

1

मैं वास्तव में जानना चाहूंगा कि यह क्यों काम किया। क्या SSH प्रोटोकॉल में कुछ ऐसा है जो बड़ी वस्तुओं पर चीट करता है जो HTTPS नहीं करता है? क्या यह ट्रांसपोर्ट लेयर का मुद्दा है?

— bdetweiler

6

मुझे यह त्रुटि तब हुई जब स्मृति से स्मृति भाग गई।

कुछ मेमोरी को खाली करना (इस मामले में: एक संकलित नौकरी खत्म करना) और फिर से मेरे लिए काम करना।

— आंद्रे लास्ज़लो
स्रोत

मेरे लिए, बहुत स्मृति उपलब्ध नहीं थी, कुछ को मुक्त करने और फिर से प्रयास करने से यह हल हो गया।

— मार्टिन कासिडी

4

मेरे मामले में यह एक कनेक्शन समस्या थी। मैं एक आंतरिक वाईफाई नेटवर्क से जुड़ा था, जिसमें मेरे पास रिसोर्स तक सीमित पहुंच थी। यह भ्रूण को लाने दे रहा था लेकिन एक निश्चित समय पर यह दुर्घटनाग्रस्त हो गया। इसका मतलब है कि यह नेटवर्क-कनेक्शन की समस्या हो सकती है। जांचें कि क्या सब कुछ ठीक से चल रहा है: एंटीवायरस, फ़ायरवॉल, आदि।

Elin3t का उत्तर इसलिए महत्वपूर्ण है क्योंकि ssh डाउनलोडिंग के प्रदर्शन में सुधार करता है ताकि नेटवर्क समस्याओं से बचा जा सके

— iberbeu
स्रोत

4

नीचे विन्यास सेट करना मेरे लिए काम नहीं करता है।

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

पिछली टिप्पणी के रूप में, यह git से मेमोरी इश्यू हो सकता है। इस प्रकार, मैं काम के धागे (32 से 8 तक) को कम करने की कोशिश करता हूं। ताकि एक ही समय में सर्वर से बहुत अधिक डेटा न मिले। फिर मैं अन्य परियोजनाओं को सिंक करने के लिए मजबूर करने के लिए "-f" भी जोड़ता हूं।

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

तब यह अब ठीक काम करता है।

repo sync -f -j8

— KimmyYang
स्रोत

2

पिछला उत्तर 512 मी पर सेट करने की अनुशंसा करता है। मैं कहूंगा कि 64 बिट आर्किटेक्चर पर प्रतिप्रश्न करने वाले सोचने के कारण हैं। Core.packedGitLimit का प्रलेखन कहता है:

डिफ़ॉल्ट 32 बिट प्लेटफार्मों पर 256 MiB और 64 बिट प्लेटफार्मों पर 32 TiB (प्रभावी रूप से असीमित) है। यह सबसे बड़ी परियोजनाओं को छोड़कर सभी उपयोगकर्ताओं / ऑपरेटिंग सिस्टम के लिए उचित होना चाहिए। आपको शायद इस मान को समायोजित करने की आवश्यकता नहीं है।

यदि आप इसे सेट करने की कोशिश करना चाहते हैं, अगर आपने इसे सेट किया है और फिर सेटिंग को हटा दें:

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

— 8DH
स्रोत

1

ध्यान दें कि Git 2.13.x / 2.14 (Q3 2017) डिफ़ॉल्ट core.packedGitLimitको प्रभावित करता है जो प्रभावित करता है git fetch:
डिफ़ॉल्ट पैक-गिट सीमा का मान बड़े प्लेटफार्मों ( 8 GiB से 32 GiB ) पर " git fetch" (पुनर्प्राप्त करने योग्य) विफलता से बचाने के लिए उठाया गया है जबकि " gc" समानांतर में चल रहा है।

डेविड टर्नर ( ) द्वारा देखें प्रतिबद्ध be4ca29 (20 अप्रैल 2017 ) । मदद-द्वारा: जेफ किंग ( ) । ^{(द्वारा विलय}^{Junio सी Hamano -}^-^में^{d97141b प्रतिबद्ध}^{, 16 मई 2017)}csusbdt
peff
^gitster

बढ़ना core.packedGitLimit

जब core.packedGitLimitपार हो जाएगा, तो गिट पैक बंद हो जाएगा।
यदि एक भ्रूण के साथ एक समानांतर ऑपरेशन चल रहा है, तो भ्रूण एक पैक खोल सकता है, और फिर पैकगिटलिमिट के हिट होने के कारण इसे बंद करने के लिए मजबूर किया जा सकता है।
रीपैक तब भ्रूण के नीचे से पैक को हटा सकता है, जिससे भ्रूण विफल हो जाएगा।

बढ़ना core.packedGitLimitइसे रोकने के लिए डिफ़ॉल्ट मान ।

वर्तमान 64-बिट x86_64 मशीनों पर, पता स्थान के 48 बिट्स उपलब्ध हैं।
ऐसा प्रतीत होता है कि 64-बिट एआरएम मशीनों में पता स्थान की कोई मानक मात्रा नहीं है (अर्थात, यह निर्माता द्वारा भिन्न होता है), और IA64 और POWER मशीनों में पूरे 64 बिट्स हैं।
तो 48 बिट्स ही एकमात्र सीमा है जिसके बारे में हम यथोचित देखभाल कर सकते हैं। हम कर्नेल के उपयोग के लिए 48-बिट एड्रेस स्पेस के कुछ बिट्स को आरक्षित करते हैं (यह कड़ाई से आवश्यक नहीं है, लेकिन यह सुरक्षित होना बेहतर है), और शेष 45 तक का उपयोग करें।
कोई भी गिट रिपॉजिटरी इस बड़े समय के आसपास कहीं भी नहीं होगी जल्द ही, इसलिए यह विफलता को रोकना चाहिए।

— VonC
स्रोत

1

@Cmpickle उत्तर का उपयोग करते हुए, मैंने क्लोन प्रक्रिया को आसान बनाने के लिए एक स्क्रिप्ट का निर्माण किया।

यह यहाँ होस्ट किया गया है: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

आप इसे निम्न पंक्ति का उपयोग करके चला सकते हैं:

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

— gianlucaparadise
स्रोत

1

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

उसके बाद मैंने अपने /etc/security/limits.conf फ़ाइल को संपादित किया जिसमें एट को निम्नलिखित पंक्तियों को जोड़ा गया: * हार्ड fsize 1000000 * सॉफ्ट fsize 1000000

वास्तव में नई सीमा मानों को "लागू" करने के लिए जिन्हें आपको फिर से लॉगिन करना होगा

— tpalanques
स्रोत

1

तात्कालिक रूप से संबंधित और केवल उपयोगी मामले में आपके पास कोई रूट नहीं है और मैन्युअल रूप से एक RPM से Git निकालें (rpm2cpio के साथ) या अन्य पैकेज (.deb, ..) को एक सबफ़ोल्डर में। विशिष्ट उपयोग मामला: आप कॉरपोरेट सर्वर पर पुराने के ऊपर Git के नए संस्करण का उपयोग करने का प्रयास करते हैं।

यदि ईआईटी उल्लेख के fatal: index-pack failed बिना git क्लोन विफल रहता है, लेकिन इसके बारे में मदद संदेश के बजाय usage: git index-pack, एक संस्करण बेमेल है और आपको --exec-pathपैरामीटर के साथ git चलाने की आवश्यकता है :

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

अपने आप ऐसा होने के लिए, अपने में निर्दिष्ट करें ~/.bashrc:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

— Tyblitz
स्रोत

1

Ssh के ऊपर git (v2.17.1) का उपयोग करके मेरे पास एक ही त्रुटि लॉग था। मेरे मामले में समाधान है:

मेरे सर्वर के गिट नंगे भंडार में प्रवेश करें।
पुकारते हैं 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 pushसमस्या से बचने के लिए git क्लाइंट की ओर से कमांड को मदद मिल सकती है।

अन्य (हैक) समाधान इतिहास के बिना अंतिम मास्टर डाउनलोड कर रहा है:

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

एक मौका है कि बफर ओवरफ्लो नहीं होगा।

— मिशाल जारू
स्रोत

0

मेरे मामले में जब प्रोटोकॉल https था तब कुछ भी काम नहीं किया था, तब मैंने ssh पर स्विच किया, और सुनिश्चित किया, मैंने पिछले प्रतिबद्ध से रेपो खींचा और पूरे इतिहास को नहीं, और विशिष्ट शाखा को भी। इससे मुझे मदद मिली:

git clone --depth 1 "ssh: .it" --branch "specific_branch"

— श्रीपद
स्रोत

0

मैंने इस बीच में किए गए सभी डाउनलोड बंद कर दिए, जिससे शायद कुछ जगह खाली हो गई और ऊपर / नीचे बैंडविड्थ साफ हो गई

— बार्टोलोमिएज वच
स्रोत

0

Git-daemon समस्या v2.17.0 में हल हो गई है (एक गैर-कार्यशील v2.16.2.1 के साथ सत्यापित) है। कंसोल में पाठ का चयन करने के लिए "लॉक आउटपुट बफर" का वर्कअराउंड आवश्यक नहीं होना चाहिए।

से https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt :

"गिट डेमॉन" के लिए फ़िक्स्ड फ़िक्स। (मर्ज ed15e58efe jk / डेमॉन-फ़िक्स को बाद में मेन्ट करने के लिए)।

— GreenMoose
स्रोत

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 संपादन के साथ। इसके बाद, आप किसी भी कमांड को ठीक और सामान्य गति से कर सकते हैं।

— विशव प्रेमलल
स्रोत

क्या मतलब है TED?

— विस्व प्रेमलल

यह "उत्तर" @ingyhere के उत्तर पर एक टिप्पणी होनी चाहिए।

— mc0e

0

यहां अधिकांश जवाबों की कोशिश की, मुझे PUTTY SSH क्लाइंट के साथ सभी संभावित नक्षत्रों के साथ त्रुटि मिली ।

एक बार जब मैंने ओपनएसएसएच पर स्विच किया तो त्रुटि हो गई थी (पर्यावरण चर GIT_SSH को हटा दें और जीआईटी बैश को पुनरारंभ करें)।

मैं एक नई मशीन और नवीनतम गिट संस्करणों का उपयोग कर रहा था। कई अन्य / पुरानी मशीनों (AWS के साथ ही) ने PUTTY के साथ-साथ बिना किसी git कॉन्फ़िगरेशन के अपेक्षित काम किया।

— मैक्स
स्रोत

0

मैंने एक ही समस्या का अनुभव किया है। REPO SSH के माध्यम से डाउनलोड किया जाना बहुत बड़ा था। जैसे @ elin3t की सिफारिश की गई है, मैंने HTTP / HTTPS पर क्लोन किया है और SSH REPO का उपयोग करने के लिए REMOTE URL init / config को बदला है ।

— Rodel
स्रोत

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

ऊपर दिए गए किसी भी समाधान ने मेरे लिए काम नहीं किया।

अंत में मेरे लिए काम करने वाला समाधान SSH क्लाइंट स्विच कर रहा था। GIT_SSH पर्यावरण चर को Windows Server 2019 द्वारा उपलब्ध OpenSSH पर सेट किया गया था। संस्करण 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

— careri
स्रोत

0

मैंने यहाँ किए गए सभी सुझावों की बहुत कोशिश की लेकिन कोई काम नहीं किया। हमारे लिए यह मुद्दा मनमौजी था और इससे भी बड़ा और बुरा यह हुआ कि बड़े पैमाने पर रिपोस बन गए (हमारे जेनकिंस विंडोज बिल्ड स्लेव पर)।

यह समाप्त हो गया ssh का संस्करण git द्वारा उपयोग किया जा रहा है। GIT को ओपन एसएसएच के कुछ संस्करण का उपयोग करने के लिए कॉन्फ़िगर किया गया था, जो यूजर्स में निर्दिष्ट हैं। उस लाइन को हटाकर इसे ठीक कर दिया। मेरा मानना है कि यह इसलिए है क्योंकि Windows अब SSH के अधिक विश्वसनीय / संगत संस्करण के साथ जहाज बनाता है जो डिफ़ॉल्ट रूप से उपयोग हो जाता है।

— aatwo
स्रोत

-1

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

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

अपनी मशीन को रिबूट करने के बाद, मैं रेपो फाइन को क्लोन करने में सक्षम था।

— पॉल स्टर्गेस
स्रोत

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

— Thxopen

-1

यदि आप विंडोज पर हैं, तो आप "इंडेक्स-पैक" विफल होने के साथ git क्लोन विफल होना चाहते हैं? ।

असल में, अपने चलाने के बाद git.exe daemon ... कमांड , उस कंसोल विंडो से कुछ टेक्स्ट का चयन करें। खींचने / क्लोनिंग का प्रयास करें, यह अभी काम कर सकता है!

अधिक जानकारी के लिए यह उत्तर देखें ।

— user276648
स्रोत

-2

सुनिश्चित करें कि आपके ड्राइव में पर्याप्त स्थान बचा है

— IndieTech समाधान
स्रोत

-3

इनमें से किसी ने भी मेरे लिए काम नहीं किया, लेकिन हेरोकू द्वारा निर्मित टूल का उपयोग करने से चाल चली गई।

heroku git:clone -a myapp

यहां प्रलेखन: https://devcenter.heroku.com/articles/git-clone-heroku-app

— jpadvo
स्रोत

घातक: प्रारंभिक EOF घातक: सूचकांक-पैक विफल

बढ़ना core.packedGitLimit

बढ़ना `core.packedGitLimit`