当前位置： 文江博客话题详情

Git 存储库重新打包失败

发布于 2024-10-14 21:12:31 字数 1759 浏览 2 评论 0原文

我有一个 git 存储库驻留在内存有限的服务器上。 当我尝试从服务器克隆现有存储库时，出现以下错误

hemi@ubuntu:$ git clone ssh://[email protected]/home/hemi/repos/articles
Initialized empty Git repository in /home/hemi/Skrivebord/articles/.git/
[email protected]'s password: 
remote: Counting objects: 666, done.
remote: warning: suboptimal pack - out of memory
remote: fatal: Out of memory, malloc failed
error: git upload-pack: git-pack-objects died with error.
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
hemi@ubuntu:$

要处理此错误，我尝试重新打包原始存储库（根据 此论坛帖子）。但它不是重新打包存储库，而是描述如何使用“git pack-objects”命令。

hemi@servername:~/repos/articles$ git repack -a -d --window-memory 10m --max-pack-size 100m
usage: git pack-objects [{ -q | --progress | --all-progress }]
        [--all-progress-implied]
        [--max-pack-size=N] [--local] [--incremental]
        [--window=N] [--window-memory=N] [--depth=N]
        [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
        [--threads=N] [--non-empty] [--revs [--unpacked | --all]*]
        [--reflog] [--stdout | base-name] [--include-tag]
        [--keep-unreachable | --unpack-unreachable 
        [<ref-list | <object-list]

服务器上安装了 Git 1.6.5.7。

原文

I have a git repository residing on a server with limited memory.
When I try to clone an existing repository from the server I get the following error

hemi@ubuntu:$ git clone ssh://[email protected]/home/hemi/repos/articles
Initialized empty Git repository in /home/hemi/Skrivebord/articles/.git/
[email protected]'s password: 
remote: Counting objects: 666, done.
remote: warning: suboptimal pack - out of memory
remote: fatal: Out of memory, malloc failed
error: git upload-pack: git-pack-objects died with error.
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
hemi@ubuntu:$

To handle this error I have tried to repack the original repository (according to this forum post). But instead of repacking the repository it describes how to use the "git pack-objects" command.

hemi@servername:~/repos/articles$ git repack -a -d --window-memory 10m --max-pack-size 100m
usage: git pack-objects [{ -q | --progress | --all-progress }]
        [--all-progress-implied]
        [--max-pack-size=N] [--local] [--incremental]
        [--window=N] [--window-memory=N] [--depth=N]
        [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
        [--threads=N] [--non-empty] [--revs [--unpacked | --all]*]
        [--reflog] [--stdout | base-name] [--include-tag]
        [--keep-unreachable | --unpack-unreachable 
        [<ref-list | <object-list]

Git 1.6.5.7 is installed on the server.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（9）

仅一夜美梦 2024-10-21 21:12:31

您的解决方案已在本地和远程为您提供了工作副本，但当远程存储库决定再次重新打包自身时，会再次出现问题。幸运的是，您可以设置配置选项，以减少在两个存储库中重新打包所需的内存量 - 这些实质上使您在重新打包时添加到默认选项中的命令行参数。因此，您应该登录到远程，更改到存储库并执行以下操作：

git config pack.windowMemory 10m
git config pack.packSizeLimit 20m

您可能希望在本地存储库上执行相同的操作。 （顺便说一句，我猜想要么你的存储库非常大，要么这些机器内存很少 - 这些值对我来说似乎非常低。）

对于它的价值，当在重新打包非常大型存储库时遇到 malloc 失败过去，我还更改了 core.packedgitwindowsize、core.packedgitlimit、core.deltacachesize、pack.deltacachesize 的值、pack.window 和 pack.threads 但听起来好像您不需要任何其他选项:)

Your solution has got you a working copy locally and remotely, but will cause problems again when the remote repository decides to repack itself again. Fortunately, you can set config options that will reduce the amount of memory needed for repacking in both repositories -- these essentially make the command line parameters that you added into the default options when repacking. So, you should log in to the remote, change into the repository and do:

git config pack.windowMemory 10m
git config pack.packSizeLimit 20m

You may want to do the same on your local repository. (Incidentally I guess that either your repository is very large or these are machines with little memory - these values seem very low to me.)

For what it's worth, when getting malloc failures on repacking very large repositories in the past, I've also changed the values of core.packedgitwindowsize, core.packedgitlimit, core.deltacachesize, pack.deltacachesize, pack.window and pack.threads but it sounds as if you don't need any further options :)

回复 原文
ら栖息 2024-10-21 21:12:31

由于无法直接访问存储库，因此无法执行重新打包，因此执行浅层克隆，然后逐渐获取，同时增加深度对我有帮助。

git clone YOUR_REPO --depth=1
git fetch --depth=10
...
git fetch --depth=100
git fetch --unshallow    //Downloads all history allowing to push from repo

希望它仍然可以帮助别人。

With no direct access to repository and hence being unable to perform a repack, performing a shallow clone and then gradually fetching while increasing depth helped for me.

git clone YOUR_REPO --depth=1
git fetch --depth=10
...
git fetch --depth=100
git fetch --unshallow    //Downloads all history allowing to push from repo

Hope it can still help someone.

回复 原文
甜｀诱少女 2024-10-21 21:12:31

我使用以下步骤解决了该问题。

  1. 将存储库从服务器签出到我的本地计算机（通过 ssh 使用原始副本）
  2. 重新打包本地存储库
    git repack -a -d --window-memory 10m --max-pack-size 20m
  3. 在服务器上创建了一个空存储库
    git init --bare
  4. 将本地存储库推送到服务器
  5. 检查是否可以克隆服务器存储库

I solved the problem using the following steps.

  1. Got repository checked out from the server to my local machine (using a raw copy over ssh)
  2. Repacked the local repository
    git repack -a -d --window-memory 10m --max-pack-size 20m
  3. Created an empty repository on the server
    git init --bare
  4. Pushed the local repository to the server
  5. Checked that it is possible to clone the server repository
回复 原文
等待我真够勒 2024-10-21 21:12:31

这并不能回答问题，但有人可能会遇到这个问题：当 pack-objects 被某种内存杀手（例如 Dreamhost 上使用的内存杀手）终止时，重新打包也可能在服务器上失败：

$ git clone project-url project-folder
Cloning into project-folder...
remote: Counting objects: 6606, done.
remote: Compressing objects: 100% (2903/2903), done.
error: pack-objects died of signal 9284.51 MiB | 2.15 MiB/s   
error: git upload-pack: git-pack-objects died with error.
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

在 Dreamhost 上，这似乎是由 mmap 引起的。 repack 代码使用 mmap 将某些文件的内容映射到内存中，由于内存杀手不够智能，它将映射的文件计为已使用的内存，当 Git 进程尝试时，它会杀死 Git 进程。 >mmap 一个大文件。

解决方案是编译自定义 Git 二进制文件并关闭 mmap 支持（配置 NO_MMAP=1）。

This does not answer the question, but somebody might run into it: repacking might also fail on the server when pack-objects is terminated by some kind of memory killer (such as the one used on Dreamhost):

$ git clone project-url project-folder
Cloning into project-folder...
remote: Counting objects: 6606, done.
remote: Compressing objects: 100% (2903/2903), done.
error: pack-objects died of signal 9284.51 MiB | 2.15 MiB/s   
error: git upload-pack: git-pack-objects died with error.
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

On Dreamhost this appears to be caused by mmap. The repack code uses mmap to map some files’ contents into memory, and as the memory killer is not smart enough, it counts the mmapped files as used memory, killing the Git process when it tries to mmap a large file.

The solution is to compile a custom Git binary with mmap support turned off (configure NO_MMAP=1).

回复 原文
帅哥哥的热头脑 2024-10-21 21:12:31

我正在使用 git 版本 1.7.0.4 并且它接受此命令。 git 版本 1.6 可能不接受此命令。

尝试使用一些随机提交创建一个新存储库。然后使用此命令重新打包。

I am using git version 1.7.0.4 and it accepts this command. It is possible that git version 1.6 doesn't accept this command.

Try creating a new repository with some random commits. Then repack it with this command.

回复 原文
感受沵的脚步 2024-10-21 21:12:31

git config --global pack.window 0

git config --global pack.window 0

回复 原文
夏有森光若流苏 2024-10-21 21:12:31

我在 ubuntu 14.10 上使用私人 github.com 存储库上的 git 2.1.0 时遇到了同样的问题。
（怀疑是企业路由器！可以在不同的wifi网络上工作，除了在工作场所）

* GnuTLS recv error (-54): Error in the pull function.
* Closing connection 2jects:  31% (183/589)   
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header

我的解决方案是，使用ssh进行git克隆（我事先设置了ssh密钥*），如下所示：

git克隆https://github.com/USERNAME/REPOSITORYNAME.git

变为：

git clone [电子邮件受保护]:USERNAME/REPOSITORYNAME.git< /p>

*: (生成ssh 密钥）

ssh-keygen -t rsa -C "[电子邮件受保护] ”

然后登录进入 github，在设置中导入 ssh 密钥，然后从 ~/.ssh/id_rsa.pub 导入。

I had the same problem on ubuntu 14.10 with git 2.1.0 on a private github.com repository.
(Entreprise router is suspected! Works on different wifi network, except at workplace)

* GnuTLS recv error (-54): Error in the pull function.
* Closing connection 2jects:  31% (183/589)   
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header

My solution was, to git clone using ssh (I set up ssh keys* beforehand), like this:

git clone https://github.com/USERNAME/REPOSITORYNAME.git

becomes:

git clone [email protected]:USERNAME/REPOSITORYNAME.git

*: (Generating an ssh key)

ssh-keygen -t rsa -C "[email protected]"

Then log into github, in settings, import ssh keys, and import it from ~/.ssh/id_rsa.pub.

回复 原文
心清如水 2024-10-21 21:12:31

就我而言，我有同样的错误消息，但问题出在 Github 端。

经过大约一个小时的维护后，他们修复了它，所有机器上的问题都得到了解决。

In my case, I had the same error message, but problem was on Github side.

After about an hour of maintenance they fixed it, and problem become resolved on all machines.

回复 原文
何以畏孤独 2024-10-21 21:12:31

就我而言，更改这些配置值并没有帮助 - GIT 仍然崩溃，错误略有不同。

有用的是简单的服务器重新启动（在我的例子中sudo shutdown -r now）。似乎有什么东西占用了服务器上的大量 RAM，因此 GIT 无法分配内存。

希望这也能帮助某人。

In my case changing those config values didn't help - GIT was still crashing with slightly different errors.

What helped was a simple server reboot (in my case sudo shutdown -r now). Seems like something was eating lots of RAM on the server, hence GIT was unable to allocate memory.

Hope this helps someone, too.

回复 原文
~没有更多了~

关于作者

春庭雪

暂无简介

文章
评论
25 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

我的痛♀有谁懂

文章 0 评论 0

我是自愿种绣球花的

文章 0 评论 0

屌丝范

文章 0 评论 0

lcx_

文章 0 评论 0

予囚

文章 0 评论 0

朦胧时间

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文