git clone 因“index-pack”失败而失败？

git clone fails with "index-pack" failed?

提问by gct

So I created a remote repo that's notbare (because I need redmine to be able to read it), and it's set to be shared with the group (so git init --shared=group). I was able to push to the remote repo and now I'm trying to clone it.

所以我创建了一个非裸的远程仓库（因为我需要 redmine 才能读取它），并且它被设置为与组共享（所以 git init --shared=group）。我能够推送到远程仓库，现在我正在尝试克隆它。

If I clone it over the net I get this:

如果我通过网络克隆它，我会得到这个：

remote: Counting objects: 4648, done.
remote: Compressing objects: 100% (2837/2837), done.
error: git-upload-pack: git-pack-objects died with error.B/s  
fatal: git-upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

I'm able to clone it locally without a problem, and I ran "git fsck", which only reports some dangling trees/blobs, which I understand aren't a problem. What could be causing this? I'm still able to pull from it, just not clone. I should note the remote git version is 1.5.6.5 while local is 1.6.0.4

我可以毫无问题地在本地克隆它，并且我运行了“git fsck”，它只报告了一些悬空的树/斑点，我认为这不是问题。什么可能导致这种情况？我仍然能够从中拉出，只是不能克隆。我应该注意远程 git 版本是 1.5.6.5 而本地是 1.6.0.4

I tried cloning my local copy of the repo, stripping out the .git folder and pushing to a new repo, then cloning the new repo and I get the same error, which leads me to believe it may be a file in the repo that's causing git-upload-pack to fail...

我尝试克隆我的本地存储副本，剥离 .git 文件夹并推送到新存储库，然后克隆新存储库，我得到相同的错误，这让我相信它可能是存储库中的一个文件导致git-upload-pack 失败...

Edit: I have a number of windows binaries in the repo, because I just built the python modules and then stuck them in there so everyone else didn't have to build them as well. If I remove the windows binaries and push to a new repo, I can clone again, perhaps that gives a clue. Trying to narrow down exactly what file is causing the problem now.

编辑：我在 repo 中有许多 windows 二进制文件，因为我只是构建了 python 模块，然后将它们粘在那里，所以其他人也不必构建它们。如果我删除 Windows 二进制文件并推送到新的存储库，我可以再次克隆，也许这提供了一个线索。现在试图准确缩小导致问题的文件的范围。

回答by Martin

The way I solved this problem is this: My git daemon is running on windows, and clients are on other computers.

我解决这个问题的方法是这样的：我的 git 守护进程在 Windows 上运行，而客户端在其他计算机上。

I found a workaround (but it will only work on windows).

我找到了一个解决方法（但它只能在 Windows 上工作）。

Start git daemon with verbose from cmd.exe:

从 cmd.exe 使用详细信息启动 git 守护进程：

"C:\Program Files\Git\bin\sh.exe" --login -i -c 'git.exe daemon --verbose  '

Not tested, if it works directly in git bash. Maybe it will.

未经测试，如果它直接在 git bash 中工作。也许会。

Then (before starting any clone, pull, fetch,...) select some text in the window (note: "Quick Edit Mode" must be enabled (can be found in: cmd.exe --> Properties (click the top left corner of your cmd window) --> Edit Options)) in which git daemon runs. That will prevent it from printing any further messages in that window.

然后（在开始任何克隆、拉、取、... cmd 窗口的一角）--> 编辑选项）），其中 git 守护程序运行。这将阻止它在该窗口中打印任何进一步的消息。

When the output thread of git daemon is blocked that way, then the error does not happen

当 git daemon 的输出线程以这种方式被阻塞时，则不会发生错误

回答by andywu

I have the same problem as you; the error message when I clone i:

我和你有同样的问题；克隆 i 时的错误消息：

Cloning into test...
remote: Counting objects: 6503, done.
remote: Compressing objects: 100% (4519/4519), done.
Connection to git.myhost.im closed by remote host.| 350 KiB/s
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

In my case, the reason is that my repository size (200M) is larger than my gitserver's memory (128M). When I clone from the gitserver, I use command topon my server, which shows that memory usage is soon over 128M.

就我而言，原因是我的存储库大小（200M）大于git服务器的内存（128M）。当我从git服务器克隆时，我top在我的服务器上使用命令，显示内存使用量很快超过 128M。

When I use another server that has 4G memory, the git cloneis all okay. You could also try adding more swap space to your sever.

当我使用另一台具有4G内存的服务器时，git clone一切正常。您还可以尝试向服务器添加更多交换空间。

回答by Yann Ramin

Does "git gc" complain?

“git gc”会抱怨吗？

回答by Nicolai Josuttis

I had the same problem. My guess also was that this has to do with the fact that I use text/CRLF mode for created files. And indeed, after switching CygWin to UNIX/binary newline mode, everything works fine.

我有同样的问题。我的猜测也是，这与我对创建的文件使用文本/CRLF 模式这一事实有关。事实上，在将 CygWin 切换到 UNIX/二进制换行模式后，一切正常。

See:

看：

• http://cygwin.com/cygwin-ug-net/using-textbinary.html
• http://www.sourceware.org/cygwin/cygwin-ug-net/using-utils.html#mount

• http://cygwin.com/cygwin-ug-net/using-textbinary.html
• http://www.sourceware.org/cygwin/cygwin-ug-net/using-utils.html#mount

BTW, the easiest way for me to switch the file mode was to edit /etc/fstab to switch from

顺便说一句，我切换文件模式的最简单方法是编辑 /etc/fstab 从

none /cygdrive cygdrive text,posix=0,user 0 0

无 /cygdrive cygdrive text,posix=0,user 0 0

to

到

none /cygdrive cygdrive binary,posix=0,user 0 0

无 /cygdrive cygdrive 二进制文件，posix=0，用户 0 0

回答by mpmeyer

I also had problems with cygwin git, the error: fatal: index-pack failed,

我也有 cygwin git 的问题，错误：fatal: index-pack failed，

I was able to solve it by creating a mount for my projects and setting it to binary mode. since my /cis set to text mode.

我能够通过为我的项目创建一个安装并将其设置为二进制模式来解决它。因为我/c的设置为文本模式。

Add cygwin's to /etc/fstab:

将 cygwin 添加到/etc/fstab：

c:/work/Projects /projects some_fs binary 0 0

run mount -ato mount all drives.

运行mount -a以安装所有驱动器。

You need to be in /projectsto work with cygwin git, /c/work/Projectswill fail.

你需要在/projects使用 cygwin git，/c/work/Projects会失败。

Not sure if this will work for you.

不确定这是否适合你。

回答by ivan_pozdeev

Use GIT_TRACEenvironment variable to get debug output. Set it to "1" to trace to stderr or an absolute path to trace to file.

使用GIT_TRACE环境变量获取调试输出。将其设置为“1”以跟踪到标准错误或绝对路径以跟踪到文件。

回答by Flávio H. Ferreira

I've the same problem and I would change my git configs to and that is worked fine:

我有同样的问题，我会将我的 git 配置更改为，这工作正常：

git config --global pack.packSizeLimit 50m
git config --global pack.windowMemory 50m
git config --global core.compression 9

git config --global pack.packSizeLimit 50m
git config --global pack.windowMemory 50m
git config --global core.compression 9

回答by GreenMoose

The git-daemon issue seems to have been resolved in v2.17.0(verified with a non working v2.16.2.1). I.e. workaround of selecting text in console to "lock output buffer" should no longer be required.

git-daemon 问题似乎已在v2.17.0 中得到解决（已通过非工作 v2.16.2.1 验证）。即不再需要在控制台中选择文本以“锁定输出缓冲区”的解决方法。

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

从https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt：

• Assorted fixes to "git daemon". (merge ed15e58efe jk/daemon-fixes later to maint).

• 对“git daemon”的各种修复。（稍后将 ed15e58efe jk/daemon-fixes 合并到维护）。

回答by Lasse Lindqvist

I had this problem or close to it but did not see the solution to my case in any of these threads.

我有这个问题或接近它，但在这些线程中的任何一个中都没有看到我的案例的解决方案。

In my case the problem was the firewall. Cloning small repositories worked anyway, but bigger ones failed. So if nothing else helps, firewall settings is worth checking out.

就我而言，问题是防火墙。克隆小型存储库无论如何都有效，但更大的存储库失败了。因此，如果没有其他帮助，防火墙设置值得一试。

回答by davenpcj

I ran into this issue, cloning a github repository from github.com, running git 2.13 on SLES 12 SP3. Tried upgrading git to latest (v2.21 at the time), but that did not resolve the issue. Tried setting git config options suggested, and many other options, with no luck.

我遇到了这个问题，从 github.com 克隆了一个 github 存储库，在 SLES 12 SP3 上运行 git 2.13。尝试将 git 升级到最新版本（当时是 v2.21），但这并没有解决问题。尝试设置建议的 git config 选项和许多其他选项，但没有运气。

Ultimately, I did it by hand.

最终，我手工完成了。

• created the directory manually.. mkdir somedir
• Ran git initto set up the directory for GIT.
• Manually added the github repo as an origin git remote add origin http://github.com/git/git
• Ran git fetchto grab the pack. This task failed with an error, but left behind the fetched-but-bad pack in .git/objects/pack/tmp_pack_XXXXXX
• used cat .git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -rto extract all the valid objects.
• Ran git fetchagain to get anything (like branches and tags) missed from the prior attempts. No pack/objects needed because they were all unpacked.
• Finally, git checkout master, to get HEADpointing at something real.

• 手动创建目录.. mkdir somedir
• Rangit init为 GIT 设置目录。
• 手动添加 github repo 作为 origin git remote add origin http://github.com/git/git
• 跑去git fetch抢包。此任务因错误而失败，但留下了已获取但错误的包.git/objects/pack/tmp_pack_XXXXXX
• 用于cat .git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -r提取所有有效对象。
• 冉git fetch再次得到任何东西（如分支和标签）从之前的尝试错过。不需要包装/物品，因为它们都已打开。
• 最后git checkout master，得到HEAD的东西真正的指向。

I'm not sure it was required for me, but I'd recommend git fsckand git gcafter that, which will also trigger git to recreate the packs/indexes.

我不知道这是需要我，但我建议git fsck，并git gc在此之后，这也将触发混帐重新创建包/索引。