我执行了git pull --rebase,然后得到了以下错误:
error: file write error (No space left on device) fatal: unable to write sha1 file fatal: unpack-objects failed
我的设备上有很多空间。不知道为什么显示此错误。我第一次得到这个错误。
quhf5bfb1#
驱动器空间不足,请删除机器上任何地方的 * 未使用的 * 文件。在做了一些大扫除之后,您可以考虑运行git gc让git垃圾回收仓库;如果你最近对git的对象做了很多修改(比如rebase),你可以从git中回收重要的数据。给git一些喘息的空间(gc在工作时需要一点空间来复制数据到新文件),git gc会尽可能压缩你的git仓库,而不会丢失仓库的历史记录。
git gc
lokaqttq2#
这并不是一个答案,更像是对问题的澄清,以及问题实际上可能是什么。我发现当我的Windows 8.1系统和驱动器上有足够的空间时,GIT会定期吐出这种类型的错误代码。运行5次并在任务管理器中检查内存后,我发现每次系统内存接近最大限制时都会触发此错误。它与可用磁盘空间无关,因此@Matt的答案可能在某些情况下是正确的,但并不是所有情况下都正确。任务管理器报告GIT使用的内存比例很低,但每次GIT运行时,它都会增加使用的内存。此问题似乎与GIT中的内存泄漏有关。
k4emjkb13#
我在推送到远程服务器时也遇到了类似的错误,实际上这不是因为本地机器上没有足够的空间,而是因为Git服务器上没有足够的空间。只需检查完整的错误,例如我得到:
Failed to write to log, write /var/log/gitlab/gitlab-shell/gitlab-shell.log: no space left on device
通知我错误来自gitlab-shell,而不是git。
gitlab-shell
git
d6kp6zgx4#
要添加到the other answer,说明:每次GIT运行时,它都会增加内存使用量。2这个问题似乎与GIT中的内存泄漏有关。Git 2.20(2018年第4季度)专注于解决Git中已知的最后几个内存泄漏案例,在ref-filter代码路径中堵塞少量内存泄漏。参见Olga Telezhnaya ( telezhnaya )的commit f0062d3、commit deec6b8、commit 23941dd(2018年10月18日)。(由Junio C Hamano -- gitster --合并至commit 9d00100,2018年10月30日)Git 2.24(Q4 2019)更正了“for-each-ref“(以及显示引用的朋友没有保护自己免受旧标签的攻击)在被要求显示“%(taggername)“时没有记录标签者的名字。参见Mischa POSLAWSKY ( shiar )的commit 8b3f33e(2019年8月17日)。(由Junio C Hamano -- gitster --合并至commit a477abe,2019年9月9日)
telezhnaya
gitster
for-each-ref
%(taggername)
shiar
ref-filter
在无标头标签上格式化$(taggername),例如Git中的v0.99,会导致SIGABRT出现错误“munmap_chunk():指针”“无效,因为在提交f0062d3(ref-filter:自由项目-〉值和项目-〉值-〉s,2018年10月19日,Git v2.20.0-rc 0).
$(taggername)
SIGABRT
munmap_chunk()
k2fxgqgv5#
在我的例子中,.gitconfig文件被保存在一个网络位置,这个位置实际上保存了我机器上的所有配置文件,这样,如果电脑死机了,公司可以在一个新的硬件上恢复相同的配置文件。无论如何,这个网络驱动器空间不足,所以git无法更新文件。或者直接断开连接,git会使用主驱动器上的本地配置文件。
bakd9h0s6#
我在使用Git Bash控制台时遇到了这个问题。通过使用Windows控制台,那里没有更多的问题。我可以克隆存储库。
7bsow1i67#
在我的情况下,它的远程设备耗尽空间,而不是本地计算机。所以,如果您的本地计算机有足够的空间,也许你应该检查远程计算机。
dluptydi8#
对我来说,这个问题是通过改变分支名称来解决的最初,我从错误的分支中提取代码,而这个分支在我的GitLab中并不存在,所以可能你使用了错误的分支名称。
zd287kbt9#
我解决了我的问题,在mac做空间在我的办公桌,如果你的办公桌是满的,它会给予这样的错误。
9条答案
按热度按时间quhf5bfb1#
驱动器空间不足,请删除机器上任何地方的 * 未使用的 * 文件。在做了一些大扫除之后,您可以考虑运行
git gc
让git垃圾回收仓库;如果你最近对git的对象做了很多修改(比如rebase),你可以从git中回收重要的数据。给git一些喘息的空间(gc在工作时需要一点空间来复制数据到新文件),git gc
会尽可能压缩你的git仓库,而不会丢失仓库的历史记录。lokaqttq2#
这并不是一个答案,更像是对问题的澄清,以及问题实际上可能是什么。我发现当我的Windows 8.1系统和驱动器上有足够的空间时,GIT会定期吐出这种类型的错误代码。
运行5次并在任务管理器中检查内存后,我发现每次系统内存接近最大限制时都会触发此错误。它与可用磁盘空间无关,因此@Matt的答案可能在某些情况下是正确的,但并不是所有情况下都正确。
任务管理器报告GIT使用的内存比例很低,但每次GIT运行时,它都会增加使用的内存。此问题似乎与GIT中的内存泄漏有关。
k4emjkb13#
我在推送到远程服务器时也遇到了类似的错误,实际上这不是因为本地机器上没有足够的空间,而是因为Git服务器上没有足够的空间。
只需检查完整的错误,例如我得到:
通知我错误来自
gitlab-shell
,而不是git
。d6kp6zgx4#
要添加到the other answer,说明:
每次GIT运行时,它都会增加内存使用量。2这个问题似乎与GIT中的内存泄漏有关。
Git 2.20(2018年第4季度)专注于解决Git中已知的最后几个内存泄漏案例,在ref-filter代码路径中堵塞少量内存泄漏。
参见Olga Telezhnaya (
telezhnaya
)的commit f0062d3、commit deec6b8、commit 23941dd(2018年10月18日)。(由Junio C Hamano --
gitster
--合并至commit 9d00100,2018年10月30日)Git 2.24(Q4 2019)更正了“
for-each-ref
“(以及显示引用的朋友没有保护自己免受旧标签的攻击)在被要求显示“%(taggername)
“时没有记录标签者的名字。参见Mischa POSLAWSKY (
shiar
)的commit 8b3f33e(2019年8月17日)。(由Junio C Hamano --
gitster
--合并至commit a477abe,2019年9月9日)ref-filter
:初始化空名称或电子邮件字段在无标头标签上格式化
$(taggername)
,例如Git中的v0.99,会导致SIGABRT
出现错误“munmap_chunk()
:指针”“无效,因为在提交f0062d3(ref-filter
:自由项目-〉值和项目-〉值-〉s,2018年10月19日,Git v2.20.0-rc 0).k2fxgqgv5#
在我的例子中,.gitconfig文件被保存在一个网络位置,这个位置实际上保存了我机器上的所有配置文件,这样,如果电脑死机了,公司可以在一个新的硬件上恢复相同的配置文件。无论如何,这个网络驱动器空间不足,所以git无法更新文件。或者直接断开连接,git会使用主驱动器上的本地配置文件。
bakd9h0s6#
我在使用Git Bash控制台时遇到了这个问题。通过使用Windows控制台,那里没有更多的问题。我可以克隆存储库。
7bsow1i67#
在我的情况下,它的远程设备耗尽空间,而不是本地计算机。所以,如果您的本地计算机有足够的空间,也许你应该检查远程计算机。
dluptydi8#
对我来说,这个问题是通过改变分支名称来解决的最初,我从错误的分支中提取代码,而这个分支在我的GitLab中并不存在,所以可能你使用了错误的分支名称。
zd287kbt9#
我解决了我的问题,在mac做空间在我的办公桌,如果你的办公桌是满的,它会给予这样的错误。