blocks|key|3162730|text|http.postBuffer的把戏对我不起作用。但是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3162731|对于其他遇到这个问题的人来说，这可能是GnuTLS的问题。如果您设置了详细模式，您可能会看到与以下代码行类似的潜在错误。|3162732|不幸的是，到目前为止，我唯一的解决方案是使用SSH。|3162733|我见过一个用OpenSSL而不是GnuTLS编译elsewhere的解决方案。对于issue+here，有一个活动的错误报告。|offset|length|3162734|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%25+(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|code-block|syntax|javascript|3162735|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/15100701/485900|1|https://bugs.launchpad.net/ubuntu/%2Bsource/gnutls26/%2Bbug/1111882^0|0|0|0|O|9|0|1B|4|1|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@$H|12|I|13|1|14]|$H|15|I|16|1|17]]|A|$]]|$1|J|3|K|5|L|7|18|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]|W|$5|R|S|T|A|$U|X]]]]

The http.postBuffer trick did not work for me. However:

For others experiencing this problem, it may be an issue with GnuTLS. If you set Verbose mode, you may see the underlying error look something along the lines of the code below.

Unfortunately, my only solution so far is to use SSH. 

I've seen a solution posted <a href="https://stackoverflow.com/a/15100701/485900">elsewhere</a> to compile Git with OpenSSL instead of GnuTLS. There is an active bug report for the issue <a href="https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1111882" rel="noreferrer">here</a>.

<pre><code>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
&gt; 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
&lt; HTTP/1.1 200 OK
&lt; Server: GitHub.com
&lt; Date: Thu, 10 Oct 2013 03:28:14 GMT

&lt; Content-Type: application/x-git-upload-pack-advertisement
&lt; Transfer-Encoding: chunked
&lt; Expires: Fri, 01 Jan 1980 00:00:00 GMT
&lt; Pragma: no-cache
&lt; Cache-Control: no-cache, max-age=0, must-revalidate
&lt; Vary: Accept-Encoding
&lt; 
* 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
&gt; 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

&lt; HTTP/1.1 200 OK
&lt; Server: GitHub.com
&lt; Date: Thu, 10 Oct 2013 03:28:15 GMT

&lt; Content-Type: application/x-git-upload-pack-result
&lt; Transfer-Encoding: chunked
&lt; Expires: Fri, 01 Jan 1980 00:00:00 GMT
&lt; Pragma: no-cache
&lt; Cache-Control: no-cache, max-age=0, must-revalidate
&lt; Vary: Accept-Encoding
&lt; 
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
</code></pre>

blocks|key|261565|text|它可能像服务器问题一样简单。如果使用GitHub，请检查https://twitter.com/githubstatus。我刚刚第一次看到这个，发现了GitHub's+having+a+wobble。几分钟后，它再次正常工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|261566|entityMap|0|LINK|mutability|MUTABLE|url|https://twitter.com/githubstatus|1|https://twitter.com/githubstatus/status/443527323938476032^0|S|W|0|23|O|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

It may be as simple as a server problem. If using GitHub, check <a href="https://twitter.com/githubstatus" rel="nofollow">https://twitter.com/githubstatus</a>. I saw this for the first time just now and discovered <a href="https://twitter.com/githubstatus/status/443527323938476032" rel="nofollow">GitHub's having a wobble</a>. A few minutes later it worked again fine.

blocks|key|259749|text|：通过调整client_max_body_size的值，更改http.postBuffer可能还需要为gitlab设置Nginx配置文件，以便为客户端接受更大的正文尺寸。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|259750|但是，如果您可以访问Gitlab机器或其网络中的机器，则有一个解决方法，那就是使用git+bundle。|BOLD|259751|259752|转到源计算机上的git资料档案库|ordered-list-item|259753|运行git+bundle+create+my-repo.bundle+--all|259754|transfer+(例如，使用rsync)+my-repo.bundle文件到目标计算机|259755|在目标计算机上，运行git+clone+my-repo.bundle|259756|git+remote+set-url+origin+"path/to/your/repo.git"|259757|git+push+|259758|259759|万事如意！|259760|entityMap^0|U|F|0|0|I|15|A|0|0|0|2|12|0|0|A|O|0|0|1D|0|0|8|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|14|8|@$9|15|A|16|B|H]|$9|17|A|18|B|C]]|D|@]|E|$]]|$1|I|3|-4|5|6|7|19|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|1A|8|@]|D|@]|E|$]]|$1|M|3|N|5|L|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|O|3|P|5|L|7|1E|8|@]|D|@]|E|$]]|$1|Q|3|R|5|L|7|1F|8|@$9|1G|A|1H|B|C]]|D|@]|E|$]]|$1|S|3|T|5|L|7|1I|8|@$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|U|3|V|5|L|7|1L|8|@$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1O|8|@]|D|@]|E|$]]|$1|X|3|Y|5|6|7|1P|8|@]|D|@]|E|$]]|$1|Z|3|-4|5|6|7|1Q|8|@]|D|@]|E|$]]]|10|$]]

Obs.: Changing <code>http.postBuffer</code> might also require to set up the Nginx configuration file for gitlab to accept larger body sizes for the client, by tuning the value of client_max_body_size.

However, there is a workaround if you have access to the Gitlab machine or to a machine in its network, and that is by making use of <code>git bundle</code>.

<ol>
<li>go to your git repository on the source machine</li>
<li>run <code>git bundle create my-repo.bundle --all</code></li>
<li>transfer (eg., with rsync) the my-repo.bundle file to the destination machine</li>
<li>on the destination machine, run <code>git clone my-repo.bundle</code></li>
<li><code>git remote set-url origin "path/to/your/repo.git"</code></li>
<li><code>git push</code> </li>
</ol>

All the best!

blocks|key|2948931|text|我也有类似的问题，不过是做竹子活。竹子无法执行缓存存储库的本地克隆(本地，但通过SSH代理)，我删除了缓存，之后它工作了，但任何时候它试图从本地缓存克隆都会失败。看起来像是竹子的SSH代理版本的问题，而不是git本身的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2948932|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I had a similar problem, but with a bamboo job. Bamboo was failing doing a local clone (local but over an SSH proxy) of a cached repository, I deleted the cache and after that it worked, but any time it tries to clone from the local cache there is a failure. Seems like a problem with bamboo's version of the SSH proxy not git per se.

blocks|key|262891|text|这对我很有效，因为没有指定标准的名称服务器，所以设置了Googles名称服务器，然后重新启动网络：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|262892|sudo+echo+"dns-nameservers+8.8.8.8"+>>+/etc/network/interfaces+&&+sudo+ifdown+venet0:0+&&+sudo+ifup+venet0:0|code-block|syntax|javascript|262893|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

This worked for me, setting up Googles nameserver because no standard nameserver was specified, followed by restarting networking:

<pre><code>sudo echo "dns-nameservers 8.8.8.8" &gt;&gt; /etc/network/interfaces &amp;&amp; sudo ifdown venet0:0 &amp;&amp; sudo ifup venet0:0
</code></pre>

blocks|key|262919|text|我在Kubuntu中使用git时遇到了这个问题。我还注意到网络的整体不稳定，并发现了一个solution。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|262920|262921|在/etc/resolv.conf中将该行添加到文件的末尾|blockquote|262922|262923|单次请求选项|262924|262925|这修复了每次域名解析之前的延迟，git在此之后开始像护身符一样工作。|262926|entityMap|0|LINK|mutability|MUTABLE|url|https://bbs.archlinux.org/viewtopic.php?id=75770^0|18|8|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|10|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|11|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|12|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|14|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

I faced with this problem using git in Kubuntu. I've also noticed overall instability in networking and found a <a href="https://bbs.archlinux.org/viewtopic.php?id=75770" rel="nofollow noreferrer">solution</a>.
<blockquote>
in /etc/resolv.conf
add the line to the end of the file
options single-request
</blockquote>
This fixed delays before every domain name resolution and git started to work like a charm after this.

blocks|key|259804|text|在/etc/resolv.conf中，将该行添加到文件的末尾|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|259805|options+single-request|code-block|syntax|javascript|259806|entityMap^0|1|G|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

in <code>/etc/resolv.conf</code> add the line to the end of the file

<pre><code>options single-request
</code></pre>

blocks|key|2949054|text|使用下面的命令后，我得到了解决方案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949055|git+repack+-a+-f+-d+--window=250+--depth=250|offset|length|style|CODE|2949056|entityMap^0|0|0|18|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I got solution after using below command:

<code>git repack -a -f -d --window=250 --depth=250</code>

blocks|key|262942|text|检查你的网速。还要检查以下命令：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|262943|$+git+config+--global+http.postBuffer+2M
$+git+pull+origin+master|code-block|syntax|javascript|262944|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Check your internet speed. Also check the following commands: 

<pre><code>$ git config --global http.postBuffer 2M
$ git pull origin master
</code></pre>

blocks|key|3162833|text|好吧，我想推动一个219MB的解决方案，但我没有运气|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3162834|git+config+--global+http.postBuffer+524288000|code-block|syntax|javascript|3162835|而拥有一个525MB的post缓冲区又有什么意义呢？这太傻了。所以我看了下面的git错误：|3162836|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|3162837|所以git想要post+5MB，然后我把post缓冲区设为6MB，它就能工作了|3162838|git+config+--global+http.postBuffer+6291456|3162839|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Well, I wanted to push a 219 MB solution, but I had no luck with 

<pre><code>git config --global http.postBuffer 524288000
</code></pre>

And what's the point of having a 525 MB post buffer anyway? it's silly. So I looked at the git error below:

<pre><code>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
</code></pre>

So git want's to post 5 MB, then I made the post buffer 6 MB, and it works

<pre><code>git config --global http.postBuffer 6291456
</code></pre>

blocks|key|257519|text|我在我的OS+X+El+Capitan+Mac上做git推送。我得到了同样的错误，我尝试了所有的方法来修复，我在google/stackoverflow上找到的东西。就版本而言，我使用的是相当新的github版本，是2.7.4。我在本地系统中创建了一个项目，并希望在我的github帐户中公开此项目。项目大小不在8MB左右。我注意到，当我推送一些大小约为1.5MB的文件时，它可以正常推送，但对于较大的文件，我无法推送，并出现相同的错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|257520|我唯一的选择就是以MB为单位推送更改。现在我已经推送了所有的更改。这是我的变通方法，直到我解决了这个问题。|257521|因此您还可以尝试在多次提交中推送更改。或者，如果您有多个文件夹，您可以按每个文件夹推送更改(如果文件夹大小不大)。|257522|希望这能帮助你在项目中继续工作。|257523|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I was doing git push from my OS X El Capitan Mac. I was getting same error, I tried everything to fix, what I found on google/stackoverflow. As far as version is concerned I am using fairly latest version of github which is 2.7.4. I have create a project in my local system, and I wanted this to be public in my github account. Project size was not around 8MB. I noticed that when I was pushing some files of size around 1.5MB, it was pushing properly, but with large size failed for me, with same error, 

Only option I had was to push changes in chunk of MB. Now I have pushed all changes. This is workaround for me until I get fix for this solution.

So you can also try pushing change in multiple commit. Or if you have multiple folder you can push changes by each folder (if folder size is not big).

Hope this will help you to continuous working on project.

blocks|key|262953|text|对我来说唯一有效的方法是使用SSH链接而不是链接来克隆存储库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|262954|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The only thing that worked for me was to clone the repo using the HTTPS link instead of the SSH link.

blocks|key|3162875|text|我发现我的问题出在.netrc文件上，如果对你来说也是这样，那么你可以这样做：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3162876|打开.netrc文件并对其进行编辑，以包含github凭据。键入nano+~/netrc或gedit+~/netrc|offset|length|style|CODE|3162877|然后包括以下内容：*machine+github.com|3162878|登录用户名|3162879|密码密码|3162880|机器api.github.com|3162881|3162882|密码机密*|3162883|您可以在其中包含您的原始密码，但出于安全考虑，请在此处的github+token中生成一个身份验证令牌并将其粘贴到您的密码的位置。|3162884|希望这能帮助到某人|3162885|entityMap|0|LINK|mutability|MUTABLE|url|https://help.github.com/articles/creating-an-access-token-for-command-line-use/^0|0|W|C|19|D|0|0|0|0|0|0|0|S|C|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@$D|16|E|17|F|G]|$D|18|E|19|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1A|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1B|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1C|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1D|8|@]|9|@]|A|$]]|$1|P|3|K|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1F|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1G|8|@]|9|@$D|1H|E|1I|1|1J]]|A|$]]|$1|U|3|V|5|6|7|1K|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

I found my problem to be with the .netrc file, if so for you too then you can do the following:

Open your .netrc file and edit it to include github credentials.
Type <code>nano ~/netrc</code> or <code>gedit ~/netrc</code>

Then include the following:
*machine github.com 

login username

password SECRET

machine api.github.com

login username

password SECRET*

You can include your raw password there but for security purposes, generate an auth token here <a href="https://help.github.com/articles/creating-an-access-token-for-command-line-use/" rel="nofollow noreferrer">github token</a> and paste it in place of your password.

Hope this helps someone

blocks|key|3162891|text|对于这个问题，我也有相同的problem.The原因，正如库蒂斯对GNUTLS的描述。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3162892|如果你有同样的原因，并且你的系统是Ubuntu，你可以通过安装ppa:git-core/ppa最新版本的git来解决这个问题，.The命令如下。|offset|length|style|CODE|3162893|sudo+add-apt-repository+ppa:git-core/ppa
sudo+apt-get+update
sudo+apt-get+git|code-block|syntax|javascript|3162894|entityMap^0|0|V|G|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@$D|Q|E|R|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|S|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I also had the same problem.The reason for this problem is as Kurtis's descriptions about GNUTLS.

If you have the same reason and your system is Ubuntu, you can solve this problem by installing the latest version of git from <code>ppa:git-core/ppa</code>.The commands are as below.

<pre><code>sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get git
</code></pre>

blocks|key|3162896|text|如果您使用的是https，并且收到错误消息。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3162897|我用https代替了http，它解决了我的问题。|3162898|git+config+--global+https.postBuffer+524288000|code-block|syntax|javascript|3162899|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

If you are using https and you are getting the error.

I used https instead of http and it solved my problem

<pre><code>git config --global https.postBuffer 524288000
</code></pre>

blocks|key|257538|text|我在使用BitBucket时遇到了同样的错误。我所做的是从我的存储库的URL中删除https，并使用HTTP设置该URL。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|257539|git+remote+set-url+origin+http://mj@bitbucket.org/mj/pt.git|code-block|syntax|javascript|257540|entityMap^0|1E|4|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

I have the same error while using BitBucket. What I did was remove https from the URL of my repo and set the URL using <code>HTTP</code>. 

<pre><code>git remote set-url origin http://mj@bitbucket.org/mj/pt.git
</code></pre>

blocks|key|3162947|text|当我从弹性豆茎管理的AWS+EC2实例上的远程git+repo克隆数据(通过HTTP)时，我遇到了这个问题。克隆本身也是在亚马逊网络服务EC2实例上完成的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3162948|我尝试了上述所有解决方案及其组合：|3162949|设置git的内存设置关闭GIT压缩，并尝试“浅”|3162950|settinghttp.maxrequestbuffer|unordered-list-item|offset|length|style|CODE|3162951|
|3162952|turning然后git+fetch+--unshallow+-请参阅fatal:+early+EOF+fatal:+index-pack+failed|3162953|3162954|tunning+GIT+http.postBuffer+git+clone+-+packedGitLimit等人，请参阅此处：fatal:+early+EOF+fatal:+index-pack+failed|3162955|3162956|tunning+|3162957|-将client_max_body_size设置为大值和0(无限制)；使用proxy_request_buffering+off;|3162958|setting+strace在/etc/resolv.conf|3162959|throttling+git客户端中设置trickle|3162960|using+git+clone|3162961|considering+options+single-request吞吐量，以跟踪git客户端|3162962|的git+clone|3162963|3162964|considering更新|3162965|3162966|在经历了这一切之后，我仍然一次又一次地面临同样的问题，直到我发现问题出在弹性负载均衡器(ELB)切断连接。在直接访问EC2实例(托管git+repo的实例)之后，我终于设法克隆了git+repo！我仍然不确定哪个ELB+(超时)参数导致了这种情况，所以我仍然需要做一些研究。|3162967|更新|BOLD|3162968|似乎通过将超时从20秒提高到300秒来更改AWS+Elastic+Load+Balancer的连接排出策略，为我们解决了这个问题。|3162969|git+clone错误和“连接排出”之间的关系很奇怪，对我们来说也不明显。连接排出超时更改可能会导致ELB配置中的一些内部更改，从而修复了连接过早关闭的问题。|3162970|这是亚马逊网络服务论坛上的相关问题(目前还没有答案)：https://forums.aws.amazon.com/thread.jspa?threadID=258572|3162971|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed/22317479#22317479|1|https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed/29355320#29355320|2|https://github.com/mariusae/trickle|3|https://forums.aws.amazon.com/thread.jspa?threadID=258572^0|0|0|0|7|L|0|0|9|L|Z|15|0|0|0|C|F|S|9|14|E|1R|15|1|0|0|0|2|K|11|S|0|0|K|7|2|0|6|9|0|C|M|0|1|9|0|0|0|0|0|0|2|0|1B|6|0|0|9|0|R|1L|3|0^^$0|@$1|2|3|4|5|6|7|21|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|22|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|23|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|24|8|@$I|25|J|26|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|27|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|28|8|@$I|29|J|2A|K|L]]|9|@$I|2B|J|2C|1|2D]]|A|$]]|$1|Q|3|N|5|6|7|2E|8|@]|9|@]|A|$]]|$1|R|3|S|5|H|7|2F|8|@$I|2G|J|2H|K|L]|$I|2I|J|2J|K|L]|$I|2K|J|2L|K|L]]|9|@$I|2M|J|2N|1|2O]]|A|$]]|$1|T|3|N|5|6|7|2P|8|@]|9|@]|A|$]]|$1|U|3|V|5|H|7|2Q|8|@]|9|@]|A|$]]|$1|W|3|X|5|H|7|2R|8|@$I|2S|J|2T|K|L]|$I|2U|J|2V|K|L]]|9|@]|A|$]]|$1|Y|3|Z|5|H|7|2W|8|@]|9|@]|A|$]]|$1|10|3|11|5|H|7|2X|8|@]|9|@$I|2Y|J|2Z|1|30]]|A|$]]|$1|12|3|13|5|H|7|31|8|@$I|32|J|33|K|L]]|9|@]|A|$]]|$1|14|3|15|5|H|7|34|8|@$I|35|J|36|K|L]]|9|@]|A|$]]|$1|16|3|17|5|6|7|37|8|@$I|38|J|39|K|L]]|9|@]|A|$]]|$1|18|3|N|5|6|7|3A|8|@]|9|@]|A|$]]|$1|19|3|1A|5|H|7|3B|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|3C|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|3D|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|3E|8|@$I|3F|J|3G|K|1G]]|9|@]|A|$]]|$1|1H|3|1I|5|6|7|3H|8|@$I|3I|J|3J|K|1G]]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|3K|8|@$I|3L|J|3M|K|L]]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|3N|8|@]|9|@$I|3O|J|3P|1|3Q]]|A|$]]|$1|1N|3|-4|5|6|7|3R|8|@]|9|@]|A|$]]]|1O|$1P|$5|1Q|1R|1S|A|$1T|1U]]|1V|$5|1Q|1R|1S|A|$1T|1W]]|1X|$5|1Q|1R|1S|A|$1T|1Y]]|1Z|$5|1Q|1R|1S|A|$1T|20]]]]

I was facing this issue when cloning data (via HTTP) from remote git repo hosted on AWS EC2 instance managed by elastic beanstalk. 
The cloning itself was also done on AWS EC2 instance.

I tried all aforementioned solutions and their combinations:

<ul>
<li>setting git's <code>http.postBuffer</code> </li>
<li>setting<code>http.maxrequestbuffer</code></li>
<li>turning off git compression and trying "shallow" <code>git clone</code> and then <code>git fetch --unshallow</code> - see <a href="https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed/22317479#22317479">fatal: early EOF fatal: index-pack failed</a></li>
<li>tunning GIT memory settings - <code>packedGitLimit</code>
et al, see here: <a href="https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed/29355320#29355320">fatal: early EOF fatal: index-pack failed</a></li>
<li>tunning nginx configuration - setting <code>client_max_body_size</code> to both big value and 0 (unlimited); setting <code>proxy_request_buffering off;</code></li>
<li>setting <code>options single-request</code> in /etc/resolv.conf</li>
<li>throttling git client throughput with <a href="https://github.com/mariusae/trickle" rel="nofollow noreferrer">trickle</a></li>
<li>using strace for tracing <code>git clone</code></li>
<li>considering update of git client</li>
</ul>

After all of this, I was still facing the same issue over and over again, until I found that issue is in Elastic Load Balancer (ELB) cutting the connection.
After accessing the EC2 instance (the one hosting git repo) directly instead of going through ELB I've finally managed to clone git repo!
I'm still not sure which of ELB (timeout) parameters is responsible for this, so I still have to do some research.

UPDATE

It seems that changing Connection Draining policy for AWS Elastic Load Balancer by raising timeout from 20 seconds to 300 seconds resolved this issue for us.

The relation between the <code>git clone</code> errors and "connection draining" is strange and not obvious to us. It might be that connection draining timeout change caused some internal changes in ELB configuration that fixed the issue with premature connection closing.

This is the related question on AWS forum (no answer yet): <a href="https://forums.aws.amazon.com/thread.jspa?threadID=258572" rel="nofollow noreferrer">https://forums.aws.amazon.com/thread.jspa?threadID=258572</a>

blocks|key|261705|text|我也有同样的问题，这与互联网连接不良有关，所以在尝试了一些git配置后，我刚刚断开了网络连接，并再次连接，它工作了！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|261706|似乎在连接中断(或者触发这种情况的操作)之后，git就卡住了。|261707|我希望它能对这里更多的人有所帮助。|261708|最好的|261709|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I had the same issue and it was related with a bad internet connection, so after try with some git configs, i've just disconnected from my network and connected again and it works!.

It seems that after connection lost (or the action that fires this situation), git is stuck.

I hope that it could be a help for someone more here.

Best,

blocks|key|263006|text|Bitbucket也有同样的错误。修复方式|type|unstyled|depth|inlineStyleRanges|entityRanges|data|263007|git+config+--global+http.postBuffer+500M
git+config+--global+http.maxRequestBuffer+100M
git+config+--global+core.compression+0|code-block|syntax|javascript|263008|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Same error with Bitbucket. Fixed by

<pre><code>git config --global http.postBuffer 500M
git config --global http.maxRequestBuffer 100M
git config --global core.compression 0
</code></pre>

blocks|key|2949173|text|这可能是因为正在推送的提交的大小..将提交数按以下步骤进行细分：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949174|git+log+-5|code-block|syntax|javascript|2949175|查看最近的5个提交，你就会知道哪些没有被推送到远程。选择一个提交id，并将所有提交推送到该id：|2949176|git+push+<remote_name>+<commit_id>:<branch_name>|2949177|备注：我刚刚检查了我的提交，它可能是最大的大小；首先推送到那时。小把戏成功了！|offset|length|style|BOLD|2949178|entityMap^0|0|0|0|0|0|3|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

It might be because of commits' size that are being pushed.. Breakdown the number of commits by the following steps:

<pre><code>git log -5
</code></pre>

See the last 5 commits and you would know which ones are not pushed to remote.
Select a commit id and push all commits up to that id:

<pre><code>git push &lt;remote_name&gt; &lt;commit_id&gt;:&lt;branch_name&gt;
</code></pre>

NOTE: I just checked my commit which could have the biggest size; first pushed up till then. The trick worked.!!

blocks|key|2949195|text|我也遇到了同样的问题，我用试错法修复了这个问题。我更改了core.compression的值，直到它正常工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949196|3次尝试后，我开始输入"git+config+--全局core.compression+1“。|2949197|"git配置--全局core.compression+4“适用于我。|2949198|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I got the same issue, 
I fixed this with trial and error method. I changed the core.compression value until it works. 

I started with "git config --global core.compression 1" after 3 attempts 

"git config --global core.compression 4" worked for me.

blocks|key|261732|text|通过WIFI路由器设置解决：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|261733|我得到了同样的问题，当我在wifi设置PPPoE(自动登录的wifi路由器)。|261734|Git下载速度非常慢，15kb。|261735|packet_write_wait:连接到17.121.133.16端口22:管道断开致命:远程端意外挂起致命:早期EOF致命:+index-pack失败|261736|解决方案:+1.将设置更改为动态IP，重新启动wifi路由器。2.从web浏览器登录到互联网服务提供商门户网站(不配置PPPoE，从wifi路由器自动登录)。|261737|更改Git后，下载速度为1.7MiB。|261738|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

SOLVED WITH WIFI Router Setting : 

I got same issue when I am in wifi with Settings PPPoE(auto login by wifi router).

Git download speed is very slow 15kb.

packet_write_wait: Connection to 17.121.133.16 port 22: Broken pipe
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Solution : 
1. Changed setting to Dynamic IP, reboot wifi router. 
2. From web browser login to Internet service provider portal (do not configure PPPoE , auto login from the wifi router).

After changing Git download speed is 1.7MiB.

blocks|key|2949205|text|这是因为互联网连接的问题，我也遇到了同样的问题。我用下面的代码做了一个浅拷贝|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949206|git+clone+--depth+1+//FORKLOCATION|code-block|syntax|javascript|2949207|稍后，使用以下命令取消对克隆的屏蔽|2949208|git+fetch+--unshallow|2949209|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

This is due the internet connectivity issue, i faced the same issue.
I did a shallow copy of code using 

<pre><code>git clone --depth 1 //FORKLOCATION
</code></pre>

Later unshallowed the clone using

<pre><code>git fetch --unshallow
</code></pre>

blocks|key|263030|text|面对同样的问题，尝试与另一个分支合并，并从他们那里拉一把。对我来说也一样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|263031|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Faced same issue, try to merge with another branch and take a pull from them.
It works for me same.

blocks|key|263033|text|使用ssh而不是http，这不是一个很好的答案，但至少对我来说是有效的|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|263034|entityMap^0|2|3|8|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

use <code>ssh</code> instead of <code>http</code>, it's not a good answer for this question but at least it works for me

blocks|key|2949237|text|基于this+answer，我尝试了以下内容(使用https+url)：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2949238|存储库的|2949239|初始克隆：|ordered-list-item|2949240|2949241|git+clone+--depth+25+url-here|style|CODE|2949242|每次尝试深度增加两次的|2949243|fetch提交：|2949244|2949245|git+fetch+--depth+50|2949246|git+fetch+--depth+100|2949247|git+fetch+--depth+200|2949248|...and等|2949249|2949250|最终(当我认为获取到足够的数据时)，我运行git+fetch+--unshallow+--然后就完成了。|2949251|2949252|这个过程显然需要更多的时间，但在我的例子中，设置http.postBuffer和core.compression并没有帮助。|2949253|更新：我发现通过+ssh+获取数据适用于任何存储库大小(偶然发现)，使用git+clone+<ssh+url>完成，假设您已经创建了ssh密钥。获取存储库后，我使用git+remote+set-url+<https+url+to+repo>更改远程地址|BOLD|2949254|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/52550078/9941549^0|2|B|0|0|0|0|0|0|T|0|0|0|0|0|K|0|0|L|0|0|L|0|0|0|L|L|0|0|O|F|14|G|0|0|2|8|5|10|J|2A|12|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@$A|1I|B|1J|1|1K]]|C|$]]|$1|D|3|E|5|6|7|1L|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1M|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1O|8|@$A|1P|B|1Q|L|M]]|9|@]|C|$]]|$1|N|3|O|5|6|7|1R|8|@]|9|@]|C|$]]|$1|P|3|Q|5|H|7|1S|8|@]|9|@]|C|$]]|$1|R|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]|$1|S|3|T|5|6|7|1U|8|@$A|1V|B|1W|L|M]]|9|@]|C|$]]|$1|U|3|V|5|6|7|1X|8|@$A|1Y|B|1Z|L|M]]|9|@]|C|$]]|$1|W|3|X|5|6|7|20|8|@$A|21|B|22|L|M]]|9|@]|C|$]]|$1|Y|3|Z|5|6|7|23|8|@]|9|@]|C|$]]|$1|10|3|-4|5|6|7|24|8|@]|9|@]|C|$]]|$1|11|3|12|5|H|7|25|8|@$A|26|B|27|L|M]]|9|@]|C|$]]|$1|13|3|-4|5|6|7|28|8|@]|9|@]|C|$]]|$1|14|3|15|5|6|7|29|8|@$A|2A|B|2B|L|M]|$A|2C|B|2D|L|M]]|9|@]|C|$]]|$1|16|3|17|5|6|7|2E|8|@$A|2F|B|2G|L|18]|$A|2H|B|2I|L|18]|$A|2J|B|2K|L|M]|$A|2L|B|2M|L|M]]|9|@]|C|$]]|$1|19|3|-4|5|6|7|2N|8|@]|9|@]|C|$]]]|1A|$1B|$5|1C|1D|1E|C|$1F|1G]]]]

Based on <a href="https://stackoverflow.com/a/52550078/9941549">this answer</a>, I tried following (with https url):

<ol>
<li>initial cloning of repo:</li>
</ol>

<code>git clone --depth 25 url-here</code>

<ol start="2">
<li>fetch commits with increasing twice per try depth:</li>
</ol>

<code>git fetch --depth 50</code>

<code>git fetch --depth 100</code>

<code>git fetch --depth 200</code>

...and so on

<ol start="3">
<li>eventually (when I think enough is fetched) I run <code>git fetch --unshallow</code> - and it's done.</li>
</ol>

The process obviously takes much more time, but in my case setting <code>http.postBuffer</code> and <code>core.compression</code> didn't help.

UPD: I found out that fetching via ssh works for any repo size (discovered accidentally), done with <code>git clone &lt;ssh url&gt;</code>, given you have created ssh keys. Once repo is fetched, I change remote address using <code>git remote set-url &lt;https url to repo&gt;</code>

blocks|key|257614|text|我也遇到了同样的问题，并在web上搜索解决方案。我发现我们在IPv6中的公司路由没有得到维护。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|257615|我关闭了(Windows10中以太网端口上的IPv6选项)，没有问题。|257616|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I had the same issue and was searching the solution around web. I found that our corporate routing in IPv6 is not maintained.

I turn off the (IPv6 option on the ethernet port in Windows 10) and there is no issue.

blocks|key|3163097|text|在通过ssh克隆存储库时，建议的解决方案对我来说都不起作用。但是，我可以使用https进行克隆，然后通过以下方式将遥控器更改为ssh：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3163098|git+remote+set-url+origin+git@github.com:USERNAME/REPOSITORY.git|code-block|syntax|javascript|3163099|entityMap^0|3|3|12|5|1R|3|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|L|$]]

None of the suggested solutions worked for me when cloning a repository via <code>ssh</code>. However, I was able to clone using <code>https</code>, then later changed the remote to <code>ssh</code> via:

<pre><code>git remote set-url origin git@github.com:USERNAME/REPOSITORY.git
</code></pre>

blocks|key|259908|text|这解决了我的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|259909|git+clone+--depth=20+https://repo.git+-b+master|code-block|syntax|javascript|259910|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

This solved my problem:

<pre><code>git clone --depth=20 https://repo.git -b master
</code></pre>

blocks|key|3163176|text|上面的技巧对我没有帮助，因为回购超过了github允许的最大推送大小。起作用的是https://github.com/git-lfs/git-lfs/issues/3758的一个建议，它建议一次推一点：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3163177|3163178|如果您的分支有很长的历史，您可以尝试一次推送较少数量的提交(例如，2000次)，如下所示：|blockquote|3163179|3163180|git+rev-list+--reverse+master+%7C+ruby+-ne+'i+%7C%7C=+0；I+%2B=+1；如果I%25+2000+$_+0‘，则放入$_%7C+xargs+-I{}+git推送原点%2B{}：refs/头/主|3163181|这将遍历master的历史，一次推送2000个对象。(当然，如果您愿意，可以在这两个位置替换不同的分支。)完成后，您应该能够最后一次推送master，并且应该是最新的。如果2000太多了，你又遇到了这个问题，你可以调整这个数字，使它更小。|3163182|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/git-lfs/git-lfs/issues/3758^0|14|1A|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|13|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]]]

The tricks above did not help me, as the repo was larger than the max push size allowed at github. What did work was a recommendation from <a href="https://github.com/git-lfs/git-lfs/issues/3758" rel="nofollow noreferrer">https://github.com/git-lfs/git-lfs/issues/3758</a> which suggested pushing a bit at a time:
<blockquote>
If your branch has a long history, you can try pushing a smaller
number of commits at a time (say, 2000) with something like this:
<pre><code>git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master
</code></pre>
That will walk through the history of master, pushing objects 2000 at a time. (You can, of course, substitute a different branch in both
places if you like.) When that's done, you should be able to push
master one final time, and things should be up to date. If 2000 is too
many and you hit the problem again, you can adjust the number so it's
smaller.
</blockquote>

blocks|key|259971|text|我必须删除git+clone命令的分支标志。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|259972|entityMap^0|5|9|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

I had to remove the branch flag for the <code>git clone</code> command.

blocks|key|2949347|text|对于共享带宽，请在负载较少时尝试克隆。否则，请尝试使用高速连接。如果仍然不起作用，请使用下面的命令，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949348|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|code-block|syntax|javascript|2949349|并再次尝试克隆。您可能需要根据可用内存大小更改这些设置。|2949350|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

For shared bandwidth try to clone when load is less. Otherwise, try with a high speed connection. If still does not work, please use below command,

<pre><code>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
</code></pre>

And try to clone again. You might need to change those settings according to your available memory size.

blocks|key|257696|text|在MacOSX+High+Sierra上，我的解决方案是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|257697|brew+install+git-lfs|code-block|syntax|javascript|257698|并且我的存储库被克隆时没有任何错误。|257699|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

On MacOSX High Sierra the solution for me was:

<pre><code>brew install git-lfs
</code></pre>

and my repository was cloned without any errors.

blocks|key|259981|text|花了几个小时尝试其中的一些解决方案，但最终发现这是由于一个公司IPS+(入侵保护系统)在传输一定数量的数据后断开了连接。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|259982|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Wasted a few hours trying some of these solutions but eventually traced this to a corporate IPS (Instrusion Protection System) dropping the connection after a certain amount of data is transferred.

blocks|key|263116|text|增加postBuffer大小和maxRequestBuffer将帮助您解决此问题。只需按照步骤操作即可。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|263117|步骤：|263118|1+.Open终端或Git+Bash，并使用"cd“转到您想要克隆存储库的位置。|263119|2.将压缩设置为0|263120|git+config+--global+core.compression+0|code-block|syntax|javascript|263121|3.设置postBuffer大小|263122|git+config+--global+http.postBuffer+1048576000|263123|4.设置maxRequestBuffer大小|263124|git+config+--global+http.maxRequestBuffer+100M|263125|5.现在开始克隆|263126|git+clone+<repo+url>|263127|6.等待克隆完成。|263128|谢谢。编码快乐！|263129|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|17|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|18|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|1A|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|1C|8|@]|9|@]|A|$K|L]]|$1|U|3|V|5|6|7|1D|8|@]|9|@]|A|$]]|$1|W|3|X|5|J|7|1E|8|@]|9|@]|A|$K|L]]|$1|Y|3|Z|5|6|7|1F|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1G|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|13|$]]

Increasing postBuffer size and maxRequestBuffer will help you in this problem. Just follow the steps.

steps:

1 .Open terminal or Git Bash and with "cd" go to the location where you wanted to clone repo.

2.Set compression to 0

<pre><code>git config --global core.compression 0
</code></pre>

3.Set postBuffer size

<pre><code>git config --global http.postBuffer 1048576000
</code></pre>

4.Set maxRequestBuffer size

<pre><code>git config --global http.maxRequestBuffer 100M
</code></pre>

5.Now start clone

<pre><code>git clone &lt;repo url&gt;
</code></pre>

6.Wait till clone get complete.

Thank you. Happy Coding !!!

blocks|key|259990|text|唯一对我起作用的是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|259991|259992|浅克隆：|ordered-list-item|259993|259994|git+clone+<yourrepo>+--depth+10|offset|length|style|CODE|259995|259996|按如下方式编辑.git/config：|259997|259998|在此之前|259999|[remote+"origin"]
++++fetch+=+%2Brefs/heads/master:refs/remotes/origin/master|code-block|syntax|javascript|260000|之后|260001|[remote+"origin"]
++++fetch+=+%2Brefs/heads/*:refs/remotes/origin/*|260002|260003|git配置--全局http.maxRequestBuffer+100M+git配置--全局core.compression+0|260004|260005|260006|Git获取|260007|260008|entityMap^0|0|0|0|0|0|V|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1D|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1F|8|@$I|1G|J|1H|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|1J|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1L|8|@]|9|@]|A|$]]|$1|S|3|T|5|U|7|1M|8|@]|9|@]|A|$V|W]]|$1|X|3|Y|5|6|7|1N|8|@]|9|@]|A|$]]|$1|Z|3|10|5|U|7|1O|8|@]|9|@]|A|$V|W]]|$1|11|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|12|3|13|5|E|7|1Q|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|16|3|17|5|E|7|1T|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|1A|$]]

The only thing that worked for me was this:
<ol>
<li>Clone shallow:
<code>git clone &lt;yourrepo&gt; --depth 10</code>
</li>
<li>Edited .git/config as follows:
</li>
</ol>
Before
<pre><code>[remote &quot;origin&quot;]
 fetch = +refs/heads/master:refs/remotes/origin/master
</code></pre>
After
<pre><code>[remote &quot;origin&quot;]
 fetch = +refs/heads/*:refs/remotes/origin/*
</code></pre>
<ol start="3">
<li>git config --global http.maxRequestBuffer 100M
git config --global core.compression 0
</li>
<li>Git fetch
</li>
</ol>

blocks|key|2949391|text|对我来说，问题出在安装在MacOS上的Norton+Security。一旦我暂时禁用了防火墙和其他诺顿保护，我的git+push就可以正常工作了。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|2949392|entityMap^0|C|5|J|F|1K|8|0^^$0|@$1|2|3|4|5|6|7|I|8|@$9|J|A|K|B|C]|$9|L|A|M|B|C]|$9|N|A|O|B|D]]|E|@]|F|$]]|$1|G|3|-4|5|6|7|P|8|@]|E|@]|F|$]]]|H|$]]

For me the problem was with Norton Security installed on MacOS. Once I've temporary disabled firewall and other Norton protections, my <code>git push</code> worked correctly.

blocks|key|260010|text|将源码树中的深度更改为25，克隆屏幕中的高级选项对我很有效|type|unstyled|depth|inlineStyleRanges|entityRanges|data|260011|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

changing depth to 25 in source tree advanced options in the clone screen worked for me

blocks|key|3163288|text|从Mac终端运行git+push...成功了，这与从导致问题的IDE+(我的案例：VSCode)尝试不同。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3163289|entityMap^0|1|3|8|B|V|3|15|6|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

Running the <code>git push...</code> from <code>Mac</code> terminal made the trick, which was different than trying from an <code>IDE</code> (my case: <code>VSCode</code>) which caused the issue.

blocks|key|263150|text|我的经验是，这肯定是某个地方的连接超时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|263151|最终通过在我的电脑上插入一个糟糕的小wifi软件狗并使用我手机的热点解决了这个问题。|263152|当我有线连接到我的ISP时，向Github上传一个小更改就可以了，所以连接和身份验证在原则上是有效的。但是当尝试推送一个新的80Mb存储库时，出现了错误。|263153|在设法将repo推送到wifi加密狗/热点之后，小的增量更改就可以正常运行。|263154|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

My experience was that this was definitely a connectivity timeout somewhere.
Eventually solved by plugging in a crappy little wifi dongle to my PC, and using my phone's hotspot.
When I was on a wired connection to my ISP, it was fine uploading a small change to Github, so connectivity and authentication worked in principle.
But when trying to push a new 80Mb repository, the error occurred.
After managing to push the repo over the wifi dongle / hotspot, small incremental changes went up fine.

My <code>git</code> client repeatedly fails with the following error after trying to clone the repository for some time.

What could be the issue here? 

Note: I have registered my SSH key with the GIT hosting provider

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

The remote end hung up unexpectedly while git cloning

负载均衡

身份验证

防火墙

服务器

Bitbucket

路由器

路由

GitHub

Ubuntu

MacOS

在尝试克隆存储库一段时间后，我的git客户端反复失败，并出现以下错误。这里的问题可能是什么？注意：我已经向GIT主机提供商注册了我的SSH密钥。Receiving objects:  13% (1309/10065), 796.00 KiB | 6 KiB/sfatal: The remote end hung up ...

问远程端在git克隆时意外挂断
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问远程端在git克隆时意外挂断EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问远程端在git克隆时意外挂断
EN