The remote end hung up unexpectedly while git cloning

后端 未结 30 2598
旧时难觅i
旧时难觅i 2020-11-22 09:02

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

What could be the issue here?

相关标签:
30条回答
  • 2020-11-22 09:22

    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 https://github.com/git-lfs/git-lfs/issues/3758 which suggested pushing a bit at a time:

    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:

    git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master
    

    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.

    0 讨论(0)
  • 2020-11-22 09:22

    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.

    0 讨论(0)
  • 2020-11-22 09:22

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

    git log -5
    

    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:

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

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

    0 讨论(0)
  • 2020-11-22 09:23

    ###Quick solution:

    With this kind of error, I usually start by raising the postBuffer size by:

    git config --global http.postBuffer 524288000
    

    (some comments below report having to double the value):

    git config --global http.postBuffer 1048576000
    

    (For npm publish, Martin Braun reports in the comments setting it to no more than 50 000 000 instead of the default 1 000 000)

    ###More information:

    From the git config man page, http.postBuffer is about:

    Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system.
    For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

    Even for the clone, that can have an effect, and in this instance, the OP Joe reports:

    [clone] works fine now


    Note: if something went wrong on the server side, and if the server uses Git 2.5+ (Q2 2015), the error message might be more explicit.
    See "Git cloning: remote end hung up unexpectedly, tried changing postBuffer but still failing".


    Kulai (in the comments) points out to this Atlassian Troubleshooting Git page, which adds:

    Error code 56 indicates a curl receive the error of CURLE_RECV_ERROR which means there was some issue that prevented the data from being received during the cloning process.
    Typically this is caused by a network setting, firewall, VPN client, or anti-virus that is terminating the connection before all data has been transferred.

    It also mentions the following environment variable, order to help with the debugging process.

    # Linux
    export GIT_TRACE_PACKET=1
    export GIT_TRACE=1
    export GIT_CURL_VERBOSE=1
    
    #Windows
    set GIT_TRACE_PACKET=1
    set GIT_TRACE=1
    set GIT_CURL_VERBOSE=1
    

    With Git 2.25.1 (Feb. 2020), you know more about this http.postBuffer "solution".

    See commit 7a2dc95, commit 1b13e90 (22 Jan 2020) by brian m. carlson (bk2204).
    (Merged by Junio C Hamano -- gitster -- in commit 53a8329, 30 Jan 2020)
    (Git Mailing list discussion)

    docs: mention when increasing http.postBuffer is valuable

    Signed-off-by: brian m. carlson

    Users in a wide variety of situations find themselves with HTTP push problems.

    Oftentimes these issues are due to antivirus software, filtering proxies, or other man-in-the-middle situations; other times, they are due to simple unreliability of the network.

    However, a common solution to HTTP push problems found online is to increase http.postBuffer.

    This works for none of the aforementioned situations and is only useful in a small, highly restricted number of cases: essentially, when the connection does not properly support HTTP/1.1.

    Document when raising this value is appropriate and what it actually does, and discourage people from using it as a general solution for push problems, since it is not effective there.

    So the documentation for git config http.postBuffer now includes:

    http.postBuffer

    Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system.
    For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally.
    Default is 1 MiB, which issufficient for most requests.

    Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard.
    Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.

    0 讨论(0)
  • 2020-11-22 09:23

    Obs.: Changing http.postBuffer 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 git bundle.

    1. go to your git repository on the source machine
    2. run git bundle create my-repo.bundle --all
    3. transfer (eg., with rsync) the my-repo.bundle file to the destination machine
    4. on the destination machine, run git clone my-repo.bundle
    5. git remote set-url origin "path/to/your/repo.git"
    6. git push

    All the best!

    0 讨论(0)
  • 2020-11-22 09:23

    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.

    0 讨论(0)
提交回复
热议问题