Git Add-致命:添加文件失败 [英] Git Add - fatal: adding files failed

问题描述

我的git-cmd.exe窗口如下:

My git-cmd.exe window looks like this:

git add "NextFolder/*"
error: unable to create temporary file: No such file or directory
error: NextFolder/SomeFile.txt: failed to insert into database
error: unable to index file 'NextFolder/SomeFile.txt'
fatal: adding files failed

我要向新的git repo添加大量文件.我有超过14,000个文件分布在根级别的大约80个文件夹中.由于数量众多，我决定一次添加并提交一个文件夹.似乎每个文件夹都有一定数量的文件，这些文件会导致"git add"操作出现致命错误(请参见上文).

I'm adding a large number of files to a new git repo. I have over 14,000 files spread out across about 80 folders in the root level. Due to the volume I've decided to add and commit one folder at a time. Seems each folder has some number of files that cause the "git add" operation to have a fatal error (see above).

我正在使用适用于Windows的Git便携式版本:

I'm using Git for Windows, portable version:

git --version
git version 2.22.0.windows.1

我认为该错误与文件的内容有关.我可以重命名该文件，将内容复制到一个新文件，重命名该文件，所有这些都无法使其正常工作.我发现，如果我在文件的最底部添加一个CRLF，则该文件的问题已修复"，但git add操作只是挂在文件夹中其他具有相同条件的文件上.

I believe the error is somehow related to the content of the file. I can rename the file, copy contents to a new file, rename that file, none of that will make it work. I've found that if I add a CRLF at the very bottom of the file the problem is "fixed" for that file but the git add operation just hangs up on some other file in the folder with the same condition.

与使用似乎没有问题的其他文件相比，我一直在使用Notepad ++来检查文件.行尾的外观相同(CRLF)，编码的外观相同(ANSI)，等等.

I've been using Notepad++ to examine the files compared to other files that seem to get added without an issue. Line endings look the same (CRLF), encoding looks the same (ANSI), etc.

该主题中的一条评论似乎是在描述我的确切问题，但这是对答案的最后一条评论，没有投票，该主题已有5年历史了.

One of the comments in this thread seem to be describing my exact problem, but it's the last comment on an answer with no upvotes and the thread is 5yr old...

git -无法创建临时文件:没有此类文件或目录-仅适用于某些文件?

我也相当确定这不是权限问题.这是我研究的第一件事，但我已将源代码完整复制到本地机器上，以将所有内容添加到git中.因此，我认为这不应该是权限问题，因为所有内容都是本地的，并且大多数文件都已添加.除非与文件量有关，或者与我使用的是Git Portable有关.

I'm also fairly certain this is not a permissions issue. That's the first thing that comes up in my research but I've copied the source code, in it's entirety, to my local machine to get everything added to git. So I'm thinking it shouldn't be a permissions issue since everything is local and most of the files are getting added. Unless it's related to the volume of files or the fact I'm using Git portable.

在撞了几个小时后，发送帮助！

Been banging my head against this for hours, send help!

我应该指出git repo与工作树是分开的.工作树位于网络驱动器S:\ paht \ to \ tree \上，存储库位于其他网络驱动器H:\ git \ test.git上.人们认为这是暂时的，我试图描述我们在(工作树)网络位置上更改的频率.一旦我对最容易流失的位置有了更好的了解，我想我们将使用典型的配置制作较小的存储库，将.git文件夹放在工作树的根目录下.

I should have pointed out that the git repo is seperate from the working tree. The working tree is on a network drive, S:\paht\to\tree\ and the repo is on a different network drive H:\git\test.git. This is thought to be temporary, I am attempting to characterize the frequency of changes we have on the (working tree) network location. Once I have better understanding of where we have the most churn, I'm thinking we will make smaller repos with the typical configuration, having the .git folder at the root of the working tree.

推荐答案

git add "NextFolder/*"

应该为git add "NextFolder":此处不需要星号/通配符，因为它是由Git bash而不是Git本身解释的.

It should be git add "NextFolder": no star/wildcard needed here, as it would be interpreted by the Git bash instead of Git itself.

首先，请确保使用简化的PATH在CMD会话中添加这些文件:这将排除其他程序影响.

First, make sure to add those files in a CMD session using a simplified PATH: that will rule out any other program influence.

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%PATH%

第二，请确保首先输入:

Second, make sure to type first:

git config core.autocrlf false

这将避免Git尝试在所有文件上转换EOL.

That will avoid Git trying to convert EOL on all files.

我在这里提到了 core.fscache ，但是在Git 2.22中，

I mentioned core.fscache here, but with Git 2.22, the issue 1989 is resolved.

执行激活core.commitGraph 并一次添加一个文件夹(和子文件夹)，并在之后提交每个添加.

Do activate the core.commitGraph and add a folder (and subfolders) at a time, with a commit done after each add.

最后，使用Git 2.22，执行激活trace2 以获得更多跟踪.

Finally, with Git 2.22, do activate trace2 for more traces.

我应该指出当我遇到错误时，我将回购与工作树分开.
它们在不同的卷上.

I should point out when I had the error I had the repo separate from the worktree.
They are on different volumes.

• 工作树在S:\path\...和
下
• .git文件夹位于H:\git\test.git
下

• The worktree is under S:\path\... and
• the .git folder is under H:\git\test.git

尝试在本地存储库C:\中克隆的本地存储库中执行git add时，问题是否仍然存在(至少.git文件夹不应该涉及网络).

Try and check if the issue persists when doing a git add in a local repository, cloned on your local disk C:\ (no network should be involved at least for the .git folder).

在Git 2.24(2019年第四季度)中，trace2也将应用于提交图形.

With Git 2.24 (Q4 2019) trace2 will be applied to commit graphs as well.

请参见提交0bd7f57 (2019年8月27日)，由 Junio C Hamano-gitster-在

See commit 0bd7f57 (27 Aug 2019) by Garima Singh (singhgarima).
^{(Merged by Junio C Hamano -- gitster -- in commit ccc2899, 15 Oct 2019)}

commit-graph :为每个子命令发出trace2 cmd_mode

^{签名人:Garima Singh
代理人:Jeff Hostetler}

commit-graph: emit trace2 cmd_mode for each sub-command

^{Signed-off-by: Garima Singh
Acked-by: Jeff Hostetler}

为每个commit-graph子命令发出trace2_cmd_mode()消息.

Emit trace2_cmd_mode() messages for each commit-graph sub-command.

当trace2使其成为Git的方式时，提交图命令不断变化.

The commit graph commands were in flux when trace2 was making it's way to Git.

现在commit-graph中有足够的子命令，我们可以在其中标记各种模式.
区分读，写和验证是一个很好的开始.

Now that we have enough sub-commands in commit-graph, we can label the various modes within them.
Distinguishing between read, write and verify is a great start.

这篇关于Git Add-致命:添加文件失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！