当前位置：theitroad>重新打包 Git 存储库失败

重新打包 Git 存储库失败

声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow 原文地址: http://stackoverflow.com/questions/4826639/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示：将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间：2020-09-10 09:57:22 　来源:igfitidea点击:

Repack of Git repository fails

gitrepository

提问by midtiby

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

我有一个 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:$

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.

为了处理这个错误，我试图重新打包原始存储库（根据这个论坛帖子）。但它没有重新打包存储库，而是描述了如何使用“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 is installed on the server.

服务器上安装了 Git 1.6.5.7。

回答by Mark Longair

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 verylarge repositories in the past, I've also changed the values of core.packedgitwindowsize, core.packedgitlimit, core.deltacachesize, pack.deltacachesize, pack.windowand pack.threadsbut it sounds as if you don't need any further options :)

对于它的价值，重新包装获得的malloc失败时非常过去大型的仓库，我也改变了价值观core.packedgitwindowsize，core.packedgitlimit，core.deltacachesize，pack.deltacachesize，pack.window和pack.threads，但它听起来好像你不需要任何进一步的选择:)

回答by mmm

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.

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

回答by midtiby

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

回答by zoul

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

这并没有回答这个问题，但有人可能会遇到它：当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

On Dreamhost this appears to be caused by mmap. The repack code uses mmapto 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 mmapa large file.

在 Dreamhost 上，这似乎是由mmap. 重新打包代码用于mmap将一些文件的内容映射到内存中，由于内存杀手不够聪明，它将映射的文件计为已用内存，当它尝试mmap大文件时杀死 Git 进程。

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

解决方案是在mmap关闭支持的情况下编译自定义 Git 二进制文件( configure NO_MMAP=1)。

回答by matthias.lukaszek

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.

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

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

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

回答by hetal

git config --global pack.window 0

git config --global pack.window 0

回答by arcol

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)

我在 ubuntu 14.10 和 git 2.1.0 的私有 github.com 存储库上遇到了同样的问题。（怀疑是企业路由器！工作在不同的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

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

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

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

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

becomes:

变成：

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

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

*: (Generating an ssh key)

*:(生成ssh密钥）

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

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

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

然后登录github，在settings中，导入ssh key，从~/.ssh/id_rsa.pub中导入。

相关推荐

我怎么能把它放到“git push”推送到本地存储库的地方？

我怎么能把它放到“git push”推送到本地存储库的地方？

git 适合二进制文件吗？

git 适合二进制文件吗？

git 如何将更改推送到远程分支

git 如何将更改推送到远程分支

git GitHub：搜索旧版本的文件

git GitHub：搜索旧版本的文件