fatal: early EOF fatal: index-pack failed

后端 未结 30 1210
滥情空心
滥情空心 2020-11-22 10:51

I have googled and found many solutions but none work for me.

I am trying to clone from one machine by connecting to the remote server which is in the LAN network.

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

    In my case it was a connection problem. I was connected to an internal wifi network, in which I had limited access to ressources. That was letting git do the fetch but at a certain time it crashed. This means it can be a network-connection problem. Check if everything is running properly: Antivirus, Firewall, etc.

    The answer of elin3t is therefore important because ssh improves the performance of the downloading so that network problems can be avoided

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

    Tried most of the answers here, I got the error with the PUTTY SSH Client with all possible constellations.

    Once I switched to OpenSSH the error was gone (remove the Environment Variable GIT_SSH and restart the git bash).

    I was using a new machine and newest git versions. On many other/older machines (AWS as well) it did work as expected with PUTTY as well without any git configuration.

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

    I got the same issue as below when I run 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
    

    Then I checked the git status, There were so many uncommitted changes I fixed the issue by committing and push all the uncommitted changes.

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

    Note that Git 2.13.x/2.14 (Q3 2017) does raise the default core.packedGitLimit which influences git fetch:
    The default packed-git limit value has been raised on larger platforms (from 8 GiB to 32 GiB) to save "git fetch" from a (recoverable) failure while "gc" is running in parallel.

    See commit be4ca29 (20 Apr 2017) by David Turner (csusbdt).
    Helped-by: Jeff King (peff).
    (Merged by Junio C Hamano -- gitster -- in commit d97141b, 16 May 2017)

    Increase core.packedGitLimit

    When core.packedGitLimit is exceeded, git will close packs.
    If there is a repack operation going on in parallel with a fetch, the fetch might open a pack, and then be forced to close it due to packedGitLimit being hit.
    The repack could then delete the pack out from under the fetch, causing the fetch to fail.

    Increase core.packedGitLimit's default value to prevent this.

    On current 64-bit x86_64 machines, 48 bits of address space are available.
    It appears that 64-bit ARM machines have no standard amount of address space (that is, it varies by manufacturer), and IA64 and POWER machines have the full 64 bits.
    So 48 bits is the only limit that we can reasonably care about. We reserve a few bits of the 48-bit address space for the kernel's use (this is not strictly necessary, but it's better to be safe), and use up to the remaining 45.
    No git repository will be anywhere near this large any time soon, so this should prevent the failure.

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

    Tangentially related and only useful in case you have no root access and manually extract Git from an RPM (with rpm2cpio) or other package (.deb, ..) into a subfolder. Typical use case: you try to use a newer version of Git over the outdated one on a corporate server.

    If git clone fails with fatal: index-pack failed without early EOF mention but instead a help message about usage: git index-pack, there is a version mismatch and you need to run git with the --exec-path parameter:

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

    In order to have this happen automatically, specify in your ~/.bashrc:

    export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec
    
    0 讨论(0)
  • 2020-11-22 11:46

    I have the same problem. Following the first step above i was able to clone, but I cannot do anything else. Can't fetch, pull or checkout old branches.

    Each command runs much slower than usual, then dies after compressing the objects.

    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
    

    This also happens when your ref's are using too much memory. Pruning the memory fixed this for me. Just add a limit to what you fetching like so ->

    git fetch --depth=100
    

    This will fetch the files but with the last 100 edits in their histories. After this, you can do any command just fine and at normal speed.

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