重新包装Git存储库失败 [英] Repack of Git repository fails

问题描述

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

  hemi @ ubuntu：$ git克隆ssh：//[e-mail]/home/hemi/repos/articles 
在/home/hemi/Skrivebord/articles/.git/中初始化的空Git存储库
 [e-mail]的密码： 
 remote：计数对象：666，完成。 
 remote：警告：次优包 - 内存不足
 remote：fatal：内存不足，malloc失败
错误：git上传包：git-pack-objects死于错误。 
致命：git upload-pack：由于远程端可能的资源库损坏而中止。 
 remote：由于远程端可能存储库损坏而中止。 
致命：早期EOF 
致命：索引包装失败
 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 | - 进度| -  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安装在服务器上。

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

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

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

在过去重新包装 大型库时，malloc失败，我还更改了 core.packedgitwindowsize ，核心的值.packedgitlimit ， core.deltacachesize ， pack.deltacachesize ， pack.window 和 pack.threads 但听起来好像你不需要任何其他选项：）

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://[e-mail]/home/hemi/repos/articles
Initialized empty Git repository in /home/hemi/Skrivebord/articles/.git/
[e-mail]'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.

解决方案

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 :)

这篇关于重新包装Git存储库失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！