Git Remote: त्रुटि: घातक: प्रोटोकॉल त्रुटि: खराब लाइन लंबाई वर्ण: Unab

120

मैंने एक जीआईटी सर्वर स्थापित किया है और अब चाहता हूं कि शुरू में क्लाइंट से अपने रेपो को आगे बढ़ाया जाए। मैंने git push origin masterइस त्रुटि संदेश का उपयोग किया और प्राप्त किया :

fatal: protocol error: bad line length character: Unab

मुझे नहीं पता कि क्या गलत हुआ। मुझे नहीं पता "Unab" क्या है। मैंने शेल का आकार बदलने की कोशिश की लेकिन यह अभी भी "उनाब" है। मुझे इस त्रुटि संदेश का हल नहीं मिल रहा है।

मैं सर्वर को "अधिकृत_की" और एसएसएच के साथ सेटअप करता हूं। (मैं SSH का उपयोग करके इसे कनेक्ट कर सकता हूं।)

यह एक जीआईटी समस्या लगती है?

BTW: सर्वर को विंडोज 7 वीएम में सेट किया गया है

git ssh authorized-keys

— user437899
स्रोत

"घातक: प्रोटोकॉल त्रुटि: खराब लाइन लंबाई चरित्र: यह" के साथ इसी तरह का मुद्दा था, मेरा त्रुटि संदेश "यह खाता वर्तमान में उपलब्ध नहीं है।"

— hj '

117

यह त्रुटि संदेश थोड़ा कठिन है, लेकिन वास्तव में आपको यह बताने की कोशिश कर रहा है कि रिमोट सर्वर ने उचित प्रतिक्रिया नहीं दी। अंततः, git-receive-packप्रक्रिया को चलाने वाले सर्वर पर एक समस्या थी ।

गिट प्रोटोकॉल में, पहले चार बाइट्स लाइन की लंबाई होनी चाहिए। इसके बजाय, वे चरित्र थे Unab... जो शायद शुरुआत में किसी तरह का त्रुटि संदेश है। (यानी, यह शायद " Unable to..." कुछ करना है)।

जब आप दौड़ते हैं तो क्या होता है ssh <host> git-receive-pack <path-to-git-repository>? आपको यह त्रुटि संदेश देखना चाहिए कि आपका git क्लाइंट बारफिंग कर रहा है और आप इसे ठीक करने में सक्षम हो सकते हैं।

— एडवर्ड थॉमसन
स्रोत

10

कि, और ssh <host> /bin/trueकुछ भी उत्पादन नहीं करना चाहिए।

— स्टीफन न्वे

9

मेरे पास यही मुद्दा था और इसका कारण मेरे .bashrc में एक 'इको "। Bashrc" था, इसलिए "घातक: प्रोटोकॉल त्रुटि: खराब लाइन की लंबाई का चरित्र: Unab" के बजाय मैं "घातक: प्रोटोकॉल त्रुटि: खराब" लंबाई देख रहा था चरित्र: .bas ”।

— स्नार्किनमेन् sn

4

ठीक है, यह मेरी समस्या भी थी: मेरी .bashrcमशीन पर, जिसने Git रिपॉजिटरी की मेजबानी की थी, जिसे मैं खींचने की कोशिश कर रहा था, जिसमें एक पंक्ति थी जो मानक आउटपुट के लिए एक प्रतिध्वनि उत्पन्न करती थी। (अर्थात्, मैं दूरस्थ मशीन पर भंडार का मालिक था, इसलिए यह मेरी .bashrcसमस्या थी।) मैंने उपयोगकर्ता ruslo द्वारा दी गई चाल का उपयोग दूसरे उत्तर में किया, अर्थात् stdout से stderr तक उस आदेश के उत्पादन को पुनर्निर्देशित करना ( some_command 1>&2)। उसके बाद, git pullफिर से काम किया।

— तेमू लीस्टी

2

उपरोक्त कमांड के साथ, आउटपुट बस हैंग होता है। यह मेरी सभी शाखाओं, एक प्रति पंक्ति, और फिर अंतिम मुद्रित लाइन पर मुझे आउटपुट 0000 और कर्सर को तुरंत सूचीबद्ध करता है जैसे कि एक और लाइन को लिखा जाना था लेकिन कभी पूरा नहीं हुआ।

— डेमोन्गोल १।

2

मुझे सात साल पुराने मुद्दे से टकराने से नफरत है, लेकिन मुझे गीट-रिसीट-पैक के साथ वही 0000 अंक मिलते हैं। चार बार रिटर्न प्रेस करने तक यह वहीं लटका रहता है, जिस बिंदु पर यह एक ही प्रोटोकॉल त्रुटि की रिपोर्ट करता है और क्विट करता है।

— मार्क ई। हैमिल्टन

60

मेरे पास समान मुद्दा था, लेकिन सटीक त्रुटि संदेश था:

घातक: प्रोटोकॉल त्रुटि: खराब लाइन लंबाई चरित्र: Usin

यह विंडोज में है, PuTTY GIT_SSHके रास्ते पर सेट है plink.exe।

संभावित समस्याएं और समाधान:

सुनिश्चित करें कि रास्ता plink.exeसही है। उदाहरण के लिए, यूनिक्स शैली का रास्ता भी ठीक काम करता है/c/work/tools/PuTTY/plink.exe
सुनिश्चित करें कि PuTTY ( pageant.exe) का प्रमुख एजेंट चल रहा है
सुनिश्चित करें कि मुख्य एजेंट में सर्वर तक पहुँचने के लिए एक वैध कुंजी है

— जानोस
स्रोत

7

मुझे विंडोज पर एक ही समस्या थी और विपरीत कारण के लिए एक ही मूल कारण निकला। मैं Cygwin (और एम्बेडेड Git SSH) का उपयोग करने की कोशिश कर रहा था, लेकिन GIT_SSH को C: \ ... \ plink.exe पर सेट किया गया था, जिससे विरोध हुआ। एक बार जब मैंने इसे हटा दिया तो सबकुछ ठीक हो गया।

— मैट होल्ट्जमैन

11

पर्यावरण चर से GIT_SSH प्रविष्टि को हटाकर मेरे लिए चाल

— चली गई

GitExt को अपग्रेड करने के बाद इसी तरह की त्रुटि को pageant और reimport .ppk कुंजी फ़ाइल को पुनः आरंभ करना पड़ा।

— बिल डोलन

9

मैं बस तमाशा में निजी कुंजी लोड करने के लिए भूल गया कि अंदर क्या समाप्त हुआ fatal: protocol error: bad line length character: git@। क्या भ्रामक त्रुटि संदेश है।

— लुडविग

1

मेरे मामले में (विंडोज 10) पेजेंट नहीं चल रहा था। एक बार मैंने इसे शुरू किया और इसमें निजी कुंजी जोड़ी, यह जस्ट वर्क किया।

— अप्रैल

28

GitExtension उपयोगकर्ताओं के लिए:

मुझे 2.19.0 पर गिट अपग्रेड करने के बाद इसी मुद्दे का सामना करना पड़ा

उपाय:

उपकरण> सेटिंग> गेट एक्सटेंशन> एसएसएच

का चयन करें [ OpenSSH ] के बजाय [ पुट्टी ]

— अमित शाह
स्रोत

जब मैंने त्रुटि प्राप्त की है तो ठीक यही मैंने किया है fatal: protocol error: bad line length character: git@। सुनिश्चित करें कि SSH कुंजी जेनरेट की गई है और GitLab में जोड़ी गई है । शायद गेट एक्सटेंशन का पुनः आरंभ आवश्यक था।

— परीक्षण

20

विंडोज पर जीआईटी स्थापित करने के बाद मुझे उसी तरह की समस्या थी। पहले तो इसने काम किया; फिर, एक दिन बाद (एक पीसी रिबूट के बाद), यह अब और नहीं हुआ, और मुझे यह मिला:

$ git pull
fatal: protocol error: bad line length character: git@

समस्या यह थी कि रिबूट के बाद, स्वचालित रूप से शुरू की गई पुट्टी "pageant.exe" में अब निजी कुंजी सक्रिय नहीं थी। जब आप पेजेंट में एक कुंजी जोड़ते हैं, तो यह डिफ़ॉल्ट रूप से एक स्थायी सेटिंग नहीं है। मुझे बस फिर से कुंजी जोड़ना था, और यह ठीक काम किया। इस प्रकार, इस मामले के लिए, स्वचालित रूप से कुंजी को लोड करना आवश्यक है, जैसा कि यहां चर्चा की गई है:

https://www.digitalocean.com/community/tutorials/how-to-use-pageant-to-streamline-ssh-key-authentication-with-putty

— MaeseDude
स्रोत

मेरे लिए स्थिति यह थी कि विज़ुअल स्टूडियो में मुझे त्रुटि मिली: "एक घातक त्रुटि के साथ असफल रहा। प्रोटोकॉल त्रुटि: खराब लाइन की लंबाई का चरित्र: गिट्टू" हर बार विंडोज फिर से चालू हो गया। पेजेंट की प्रक्रिया बिल्कुल भी शुरू नहीं की गई थी। मुझे उदाहरण के लिए TortoiseGit का उपयोग करने की आवश्यकता है जिसने इसे पृष्ठभूमि पर हल किया और फिर GIT ने विज़ुअल स्टूडियो में एक आकर्षण की तरह काम किया।

— होनज़ा पी। Hon

18

हो सकता है कि आपके पास सर्वर में .bashrc है जो आउटपुट उत्पन्न करता है। मैं, उदाहरण के लिए यह था:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
rvm use ruby-1.9.3-p194@rails32

इस मामले में rvm के उपयोग से आउटपुट (गलत तरीके से) समझा जाएगा जो गिट से आ रहा है। तो इसे द्वारा प्रतिस्थापित करें:

rvm use ruby-1.9.3-p194@rails32 > /dev/null

— क्रिस्टर फर्स्टस्ट्रॉम
स्रोत

मेरे (विंडोज़ 10) मामले में, समस्या मेरे cmd स्टार्टअप init.cmd स्क्रिप्ट पर कुछ docker संबंधित कमांड्स का आउटपुट थी (जो मैंने उन निर्देशों द्वारा बनाई थी: stackoverflow.com/questions/17404165/…)। लेकिन यह एक ही प्रिंसिपल है। धन्यवाद!

— ईटी-सीएस

यह मेरे लिए मामला था। मेरे .bashrc में 'बैनर' कमांड था। यह टिप्पणी करते हुए इस मुद्दे को तय किया। धन्यवाद :)।

— जैमी

12

गिट एक्सटेंशन में SSH निजी कुंजी लोड करने के बाद, यह समस्या हल हो जाती है।

— स्टेनली इमैनुएल
स्रोत

1

मेरे लिए - पेजेंट में ssh निजी कुंजी जोड़ना

— Nick Grealy

10

आप से किसी भी उत्पादन अनुप्रेषित कर सकते हैं .bashrcकरने के लिए stderr:

# inside .bashrc
echo 'some error/warning/remind message' 1>&2

git इस प्रतीकों की अनदेखी करेगा

वो मेरे लिए किया गया। मैं एक बयान था rvm use 2.0.0-p353मेरे में .bashrcहै, जो उलझन में है चाहिए git pull। अपील करने 1>&2और फिर से कोशिश करने के बाद , git pullठीक काम किया।

— तेमू लीस्टी

7

मुझे गिट बैश का उपयोग करके विंडोज पर एक समान समस्या थी। मुझे यह त्रुटि तब मिली जब मैं एक क्लोन क्लोन करने की कोशिश कर रहा था। रिपॉजिटरी लिनक्स बॉक्स पर थी जिसमें GitLab स्थापित था।

git clone git@servername:path/to/repo
fatal: protocol error: bad line length character: git@

मैंने सुनिश्चित किया कि ssh कुंजी जेनरेट की गई थी। सार्वजनिक कुंजी GitLab पर जोड़ी गई थी। Ssh- एजेंट चल रहा था और उत्पन्न की गई कुंजी को जोड़ा गया था ( github लिंक )।

मैं विकल्पों से बाहर भाग गया और फिर आखिर में Git Bash को बंद करने और 'Run as Administrator' पर राइट क्लिक करके इसे फिर से खोलने की कोशिश की। उसके बाद काम किया।

— syclee
स्रोत

मैं एक ही चीज़ (विंडोज 10 64-बिट) देखता हूं, लेकिन व्यवस्थापक के रूप में इसे ठीक नहीं करता।

— एड एविस

4

मेरे पास इसके बारे में एक कारण है। यदि आपके पास ssh कीपेयर सेट नहीं है (या यह किसी कारण से पठनीय नहीं है) तो ssh एक पासवर्ड के लिए संकेत देता है। विंडोज पर मानक आउटपुट और कंसोल आउटपुट के बीच कोई स्पष्ट अंतर नहीं है, इसलिए पासवर्ड प्रॉम्प्ट stdout में जाता है: "git @ जो भी पासवर्ड है:"। इसे git द्वारा दूषित प्रोटोकॉल आउटपुट के रूप में देखा जाता है।

— एड एविस

@EdAvis धन्यवाद! मुझे भी यही समस्या थी और आपकी टिप्पणी पढ़ने के बाद मैंने अपने प्रमुख एजेंट (जो आमतौर पर मेरी मशीन पर स्टार्टअप पर चलाया जाता है) की जाँच की। यह पता चला कि यह किसी कारण से नहीं चल रहा था ...

— ग्रिडो

5

यह किसी की मदद कर सकता है। जब मैं EC2 उदाहरण से किसी प्रोजेक्ट को क्लोन करने की कोशिश कर रहा था, तो मुझे नीचे की त्रुटि मिल रही थी:

Cloning into 'repo1'...
fatal: protocol error: bad line length character: logi

मेरे लिए संकल्प में निम्न चरण शामिल हैं:

सुनिश्चित करें कि ECH उदाहरण में SSH कुंजी (सार्वजनिक) को जोड़ा / अपडेट किया गया है।
प्रमाणीकरण एजेंट सुनिश्चित करें (मेरे मामले में इसका पेजेंट = पुट्टी ऑथेंटिकेशन एजेंट) चल रहा है और संबंधित निजी कुंजी भरी हुई है।
Git क्लोन के लिए सार्वजनिक कुंजी के लिए EC2 SSH कुंजी ID का उपयोग करें। उदाहरण:

git क्लोन ssh: // {SSH Key ID Ideal@someaccount.amazonaws.com/v1/repos/repo1

— acveer
स्रोत

4

नोट: यह इसलिए है क्योंकि आप पलक का उपयोग कर रहे हैं, और यदि आप करते हैं plink <server_name> lsतो पहली बात यह है कि स्टिंकआउट करने के लिए प्रिंट करता है login as, जो कुछ महत्वपूर्ण के रूप में व्याख्या करने की कोशिश करता प्रतीत होता है। एक त्वरित सुधार बस unset GIT_SSHऔर है unset SVN_SSH। अधिक जानकारी के लिए यहाँ

— Pod

@Pod तुम ठीक कह रहे, खिड़कियों पर इन आदेशों की मदद करनी चाहिए: set GIT_SSH=औरset SVN_SSH=

— Maksim Kostromin

टीएफएस के साथ मेरे पास भी यही मुद्दा था। कुंजी आईडी जोड़ने के बाद सब कुछ ठीक काम करता है, धन्यवाद!

— आंद्रे हॉफमिस्टर

4

मेरे लिए यह क्योंकि मैं हाल ही में जोड़ा गया था

RequestTTY force

में। ssh / config

इस पर टिप्पणी करते हुए इसे काम करने की अनुमति दी

— थु 01 जनवरी 1970 000000 GMT
स्रोत

3

"इको" बयानों के लिए रिमोट मशीन से कनेक्ट करने के लिए उपयोग किए जाने वाले खाते पर अपनी स्टार्टअप फ़ाइलों की जांच करें। बैश शेल के लिए ये आपके .bashrc और .bash_profile आदि होंगे। एडवर्ड थॉमसन अपने उत्तर में सही हैं, लेकिन एक विशिष्ट मुद्दा जो मैंने अनुभव किया है, वह यह है कि एसटीपी के माध्यम से एक सर्वर पर लॉगिन करने पर कुछ बॉयलर-प्लेट प्रिंटआउट होता है। गिट उस बॉयलर-प्लेट के पहले चार बाइट्स प्राप्त करेगा और इस त्रुटि को बढ़ाएगा। अब इस विशिष्ट मामले में मैं अनुमान लगाने जा रहा हूं कि "Unab" वास्तव में "Unable ..." कार्य है जो संभवतः इंगित करता है कि Git होस्ट पर कुछ और गलत है।

— snarkyname77
स्रोत

3

मेरे मामले में लाने के बाद यह लिखा था: fatal: protocol error: bad line length character: Pass। इसके अलावा धक्का के बाद मुझे मिल गया: fatal: protocol error: bad line length character: git@ Done।

विंडोज के रिबूट के बाद मुझे फिर से "PuTTY एजेंट" (pageant.exe) शुरू करना था और एक निजी कुंजी जोड़ना था जो कुंजी की सूची से गायब हो गई थी।

— CoolMind
स्रोत

2

FYI करें मुझे एक ही त्रुटि संदेश मिला जब मैंने CentOS6 कंटेनर को CentOS7 में अपग्रेड किया - कंटेनर बनाते समय कुछ गिट संचालन विफल होने लगे, उदा।

# git remote show origin
fatal: protocol error: bad line length character: Inva

चल ssh ने मुझे एक त्रुटि दी जो मैं खोज सकता था:

# ssh git@bitbucket.org
Invalid clock_id for clock_gettime: 7

इसने मुझे https://github.com/wolfcw/libfaketime/issues/63 पर ले गया, जहां मुझे एहसास हुआ कि मैं भूल गया था कि मैं LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1एक माता-पिता डॉकरीफाइल में था। टिप्पणी करना कि त्रुटि ठीक हो गई।

— जमशीद
स्रोत

2

मेरे मामले में समस्या 32-बिट पुट्टी और pageant.exe थी - यह 64-बिट TortoisePlink.exe के साथ संवाद नहीं कर सकता है। 32-बिट पुट्टी को 64-बिट संस्करण के साथ बदलने से समस्या हल हो गई।

— निकोलाई कौडेलिया
स्रोत

2

मेरे पास वही त्रुटि थी "fatal: protocol error: bad line length character: shmi" जहां shmiमेरे मामले में उपयोगकर्ता नाम है। मैंने SST को PuTTY से OpenSSH में बदल दिया "Git Extensions->Settings->SSH"। यह मदद करता है।

— वैल
स्रोत

1

मुझे वही समस्या थी जो क्रिस्टर फ़र्नस्ट्रॉम की थी। मेरे मामले में यह एक संदेश था जिसे मैंने अपने .bashrc में डाला था जो याद दिलाता है कि जब मैंने एक-दो दिनों में एक नहीं किया तो मैं बैकअप कैसे करूं।

— क्रिस्टोफर विकी
स्रोत

1

निम्नलिखित किसी की मदद कर सकते हैं: जब मैं अपने AWS EC2 उदाहरण पर एक परियोजना को क्लोन करने की कोशिश कर रहा हूं तो मुझे निम्नलिखित त्रुटि मिल रही थी:

Cloning into 'AWSbareRepo'...
fatal: protocol error: bad line length character: Plea

यह EC2-USER के बजाय रूट के रूप में ssh करने की कोशिश करने के कारण हुआ। अगर आप वास्तव में एक git क्लोन किए बिना ssh करते हैं ... तो आपको त्रुटि संदेश दिखाई देगा "कुछ कृपया ec2-user के साथ लॉगिन करें" एक बार जब मैंने g2 क्लोन को ec2-user के रूप में किया तो यह अच्छा था।

— ConfusedDeer
स्रोत

1

मैं भी एक बार उस त्रुटि का सामना करता हूं, लेकिन जब ऐसा होता है, तो इसका मतलब है कि मेरी शाखा अप-टू-डेट नहीं है इसलिए मुझे करना है git pull origin <current_branch>

— bonbon.langes
स्रोत

1

Git पासवर्ड के लिए संकेत नहीं देता है और समान गुप्त संदेश "घातक: प्रोटोकॉल त्रुटि: खराब लाइन लंबाई चरित्र: उपयोगकर्ता" के साथ विफल रहता है यदि आपके पास अपना निजी कुंजी प्रमाणीकरण सेटअप नहीं है ।

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server बताता है कि सर्वर पर सार्वजनिक कुंजी कैसे निर्दिष्ट करें। मूल रूप से सार्वजनिक कुंजी को ~ / .sh / अधिकृत_कीप या ~ / .Ssh / प्राधिकृत_की_2 में जोड़ें

मुझे विंडोज़ मशीन पर गिट बैश को निजी कुंजी प्रदान करने के तरीके पर थोड़ा संघर्ष करना पड़ा। दान मैकक्लेन का जवाब /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801##2801 में वर्णित है। उनके जवाब के अलावा, मेरे मामले में निजी कुंजी फ़ाइल को id_rsa.pub नाम दिया गया था

— संदीप
स्रोत

1

मेरे लिए निजी कुंजी (पुट्टीजेन के साथ कन्वर्ट) के साथ पुट्टी में समान मेजबान विवरण जोड़ने का काम किया। कोई भी बिट्स कमांड उसके बाद कोई समस्या नहीं थी।

— डेविड अलेउ
स्रोत

1

अगर आप पुट्टी का इस्तेमाल करते हैं। फिर सुनिश्चित करें कि पेजेंट चल रहा है और आपकी निजी कुंजी पेजेंट में लोड हो गई है (टास्कबार पर पेजेंट आइकन पर माउस राइट-क्लिक करें और पॉप अप करने वाले मेनू पर "कुंजी देखें" पर क्लिक करें)।

अन्यथा जब आप cmd.exe में करते हैं:

git clone ssh://name@host:/path/to/git/repo.git

आपको यह संदेश "घातक: प्रोटोकॉल त्रुटि: खराब लाइन की लंबाई का चरित्र:"

— डेवलपर Marius Marilėnas
स्रोत

1

टी एल; डॉ: Do नहीं छोड़ username@अपने रिमोट यूआरएल में जब विंडोज पर।

डिफ़ॉल्ट ssh के साथ लिनक्स और विंडोज पर, आप दूरस्थ URL से उपयोगकर्ता नाम को छोड़ सकते हैं, जैसे:

git clone server-name:/srv/git/repo-name

क्योंकि ssh का डिफ़ॉल्ट व्यवहार केवल उस उपयोगकर्ता नाम का उपयोग करना है जिसे आप वर्तमान में लॉग इन कर रहे हैं। यदि आप विंडोज पर हैं और इसका उपयोग करने के लिए गिट सेट किया है plink.exeताकि आप अपने में लोड की गई कुंजी का उपयोग कर सकें pageant, तो यह काम नहीं करेगा, क्योंकि plinkइसमें एक ही स्वचालित उपयोगकर्ता नाम व्यवहार नहीं है, जिसके परिणामस्वरूप उन गुप्त त्रुटि संदेश हैं, क्योंकि यह होगा उपयोगकर्ता नाम के लिए संकेत:

$ plink server-name
login as: _

बनाम:

$ plink username@server-name
...logs you in...

यदि आप पहले से ही किसी तरह एक रिपॉजिटरी क्लोन कर चुके हैं तो आप रिमोट यूआरएल को .git/configजोड़कर अपने में रीमोट्स को ठीक कर सकते हैं username@।

— jlh
स्रोत

रिमोट से उपयोगकर्ता नाम जोड़ने से git remote set-url origin myusername@...मुझे मदद मिली।

— मैक्सिम सुसलोव

0

जाँच करें कि क्या सर्वर पर शेल एक्सेस की अनुमति है।

— perpetual_dream
स्रोत

मेरा "हाय जी" था। पता चलता है कि मैंने कुछ सुरक्षा सेटअप वेबसाइट का अनुसरण किया है और अब मेरा गिट लॉगिन कहता है "हाय गिट! आप सफलतापूर्वक प्रमाणित हो गए हैं, लेकिन मैं इंटरैक्टिव शेल एक्सेस प्रदान नहीं करता हूं।" लगता है कि बीमार को दूर करना है ....

— उज्ज्वल

0

त्रुटि में परिवर्तित: घातक: प्रोटोकॉल त्रुटि: खराब लाइन लंबाई चरित्र: fata

सिस्टम पथ में git-upload-pack का स्थान जोड़ने के बाद।

समस्या को रिपॉजिटरी नाम के आसपास जोड़ा गया एक एपोस्ट्रोफ लगता है: प्रोसेस मॉनिटर (एसआईएस इंटर्ल्स से) जैसे टूल के साथ देख रहे हैं, जो गिट क्लाइंट द्वारा जोड़े गए थे। यह एक जीआईटी विशिष्ट विंडोज़ समस्या लगती है।

मैंने सर्वर के प्रॉम्प्ट में एक ही कमांड लाइन की कोशिश की: पूर्ण त्रुटि "घातक थी: किसी दिए गए रिपॉजिटरी (या किसी भी मूल निर्देशिका) की नहीं:।

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

— राज़्वान
स्रोत

0

हम इसमें भी भागे।

Counting objects: 85, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (38/38), 3.38 KiB | 0 bytes/s, done.
Total 38 (delta 33), reused 0 (delta 0)
Auto packing the repository for optimum performance.
fatal: protocol error: bad line length character: Remo
error: error in sideband demultiplexer

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

— anr78
स्रोत

0

यह आपकी मशीन पर एक सुरक्षा पहुंच हो सकती है, क्या आप पेजेंट (जो एक पोटीन एजेंट है) चला रहे हैं?

— केविन डेविस
स्रोत

0

आप हमेशा अपने गिट परियोजना के लिए http लिंक कर सकते हैं। आप ssh लिंक के बजाय इसका उपयोग कर सकते हैं। यह आपके पास सिर्फ एक विकल्प है

— Mohanakrrishna
स्रोत

0

खैर, मेरे पास यही मुद्दा था (विंडोज 7)। पासवर्ड द्वारा रेपो प्राप्त करने का प्रयास करें। मैं Git Bash + Plink (पर्यावरण चर GIT_SSH) + पेजेंट का उपयोग करता हूं। GIT_SSH (अस्थायी) हटाने से मुझे मदद मिलती है। मुझे नहीं पता कि मैं एक ही समय में RSA के साथ पास और लॉगिन करके लॉगिन का उपयोग क्यों नहीं कर सकता ...

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

0

यहां देर से जवाब, लेकिन उम्मीद है कि यह किसी की मदद करेगा। यदि इसकी प्रोटोकॉल त्रुटि है, तो इसे आपके स्थानीय गिट के साथ कुछ करना होगा जो रिमोट गिट के लिए संवाद करने में सक्षम नहीं है। यह तब हो सकता है जब आपने रेपो को ssh के माध्यम से क्लोन किया हो और कुछ समय बाद, आपने रेपो की चाबी खो दी हो या आपका ssh एजेंट अब उन कुंजियों को नहीं खोज सकता है।

उपाय

एक नई कुंजी बनाएं और इसे अपने git रेपो में जोड़ें या कुंजियों को लोड करने के लिए अपने ssh एजेंट को कॉन्फ़िगर करें यदि आपके पास अभी भी आपके पास कुंजी है और किसी और के साथ नहीं है;)
एक और त्वरित सुधार अपने पर जाने के लिए है .gitनिर्देशिका और संपादित configफ़ाइल के [remote "origin"] urlसे gitकरने के लिए httpइतना है कि SSH कुंजियों को पुश करने के लिए आवश्यक नहीं हैं और यह अपने यूज़रनेम और पासवर्ड पूछ पर लौट जाएगा।
```
[remote "origin"]
url = git@gitlab.*****.com:****/****.git
fetch = +refs/heads/*:refs/remotes/origin/*
```

में बदलो

    [remote "origin"]
    url = http://gitlab.*****.com/****/****.git
    fetch = +refs/heads/*:refs/remotes/origin/*

— cherit
स्रोत

0

सेटिंग्स / संस्करण नियंत्रण / git के तहत निर्मित से नैटिव में ssh को एक्सटेक्ट करने योग्य बदलने से मेरे लिए चाल चली गई।

— Hakaishin
स्रोत