$ git ls-files -s | grep ^100644 | cut -f2 |
git hash-object --stdin-paths --literally >/dev/null
fatal: could not open 'builtin/var.c' for reading: Too many open files
在此修补程序之后,它将成功完成。 在Git 2.39中,我的一个仓库显示了这个错误:
vonc@vclp MINGW64 ~/git/seec2 (main)
$ git ls-files -s | grep ^100644 | cut -f2 | git ls-files -s | grep ^100644 | cut -f2 | \
git hash-object --stdin-paths --literally
fatal: could not open 'data/commits/7f/a3338870d66dd3946c5c3a0bd09dadb798893d' for reading: Too many open files
4条答案
按热度按时间6ss1mwsb1#
这是一个老问题,但有一件事需要澄清:
这个问题和下面的答案讨论的是文件的Git哈希,它与问题中所问的*"此文件的SHA1"* 不完全相同。
简而言之:
如果你想得到index中文件的Git哈希值--参见CB Bailey的答案:
如果你想得到文件系统中任何文件的Git哈希值--请看cnu的答案:
如果你想获取文件系统中任何文件的Git哈希值,而你没有安装Git:
(The上面显示了Git散列实际上是如何计算的-它不是文件的sha1和,而是字符串**"blob SIZE\0CONTENT"的sha1和,其中"blob"字面上是字符串"blob"(后跟空格),SIZE是文件大小(以字节为单位)(ASCII十进制),"\0"为空字符,CONTENT为实际文件内容)。
如果您只想获得"此文件的SHA1"**,如问题中所问:
如果没有
sha1sum
,可以使用shasum -a1
或openssl dgst -sha1
(输出格式略有不同)。pcww981p2#
您需要
git ls-files
的-s
选项,这将为您提供索引中文件的模式和sha1散列。请注意,您不需要
git hash-object
,因为这将为您提供当前工作树中文件的sha1 id,而不是您添加到索引中的文件的sha1 id。一旦您在git add
之后对工作树副本进行更改,这些将有所不同。odopli943#
pxyaymoc4#
警告:如果你需要在 * 太多 * 文件上获取SHA1,你会得到一个错误,因为Git 2.40(Q1 2023)修复了一个漏洞:
参见Jeff King (
peff
)(2023年1月18日)。(由Junio C Hamano --
gitster
--合并至commit 630ae5e,2023年1月27日)hash-object
:使用--字面意思修复描述符泄漏签署人:杰夫·金
在
hash_object()
中,我们为每个要散列的文件打开一个描述符(无论是从命令行还是--stdin-paths
获得文件名),但从不关闭它。对于传统的代码路径,它将结果提供给
index_fd()
,这是可以的;它为我们关闭描述符。但是5ba9a93("
hash-object
:add
(man)--literally
选项",2014 - 09 - 11,Git v2.2.0-rc0--merge)添加了第二个代码路径,它不关闭描述符。在这方面,我们需要自己这样做。
您可以在git.git的克隆中看到这样的问题:
在此修补程序之后,它将成功完成。
在Git 2.39中,我的一个仓库显示了这个错误: