Git初始化:致命:无法将'core.filemode'设置为'false' [英] Git init: fatal: could not set 'core.filemode' to 'false'

问题描述

使用Team City从Git Repo签出. (如果需要的话，Gitlabs)

Using Team City to check out from a Git Repo. (Gitlabs if it matters)

从空"构建目录开始.遇到此错误:

Start with Empty build directory. Get this error:

致命:无法将'core.filemode'设置为'false'

fatal: could not set 'core.filemode' to 'false'

(如果重要，请在Windows计算机上运行)

(Running on a Windows machine, if that matters)

运行Team City的用户已更改为管理员，以防万一.

The user that Team City is running on was changed to an Admin just in case.

退出此命令后，.Git目录不是有效的存储库.

The .Git directory is not a valid Repo when this command exits.

清除整个工作"目录无济于事.

Wiping the entire 'work' directory doesn't help.

它随机来去去...

这: git config --global --replace-all core.fileMode false

AND this: git config --global --replace-all core.fileMode false

没有任何用处-带有或不带有--replace-all，并以admin或其他用户身份运行(如果将'false'更改为'true'，则将得到相同的错误，如果将其更改为'falseCD'它将错误更改为无效值-很明显，它正在更改它.

Does nothing useful - with or without the --replace-all, and run as admin, or another user (if you change 'false' to 'true' you get the same error, if you change it to 'falseCD' it changes the error to that being an invalid value - so clearly, it is changing it.

有人有什么主意吗?

推荐答案

Traderhunt Games traced this to some antivirus software, which makes sense. The reason has to do with the process Git uses to update a configuration entry.

运行git config并被告知要更改一个或多个配置key = value字段时，例如将core.filemode更改为false，它的实现方式是使用三步过程:

When git config runs and is told to change one or more configuration key = value field(s), such as changing core.filemode to false, the way it implements this is to use a three-step process:

1. 使用创建文件的OS服务调用创建一个新的空文件(.git/config.lock)，否则将失败(如果文件已存在).如果此步骤失败，则表明另一个git config(或等效命令)已在运行 ，我们必须等待它完成后再执行自己的git config.

1. Create a new, empty file (.git/config.lock), using the OS service call that creates a file, or fails if the file already exists. If this step fails, that indicates that another git config (or equivalent) command is already running and we must wait for it to finish before we do our own git config.

读取现有配置文件，一次读取一个key = value条目.如果密钥是我们关心的密钥，请写入 new key = value值，否则复制现有的key = value.

Read the existing configuration file, one key = value entry at a time. If the key is the one that we care about, write the new key = value value, otherwise copy the existing key = value.

在这里有些奇想，允许重复的键，而只能重复一次的键；有关详细信息，请参见git config的--replace-all和--unset-all选项.请注意，git config本身对大多数键和值对一无所知，并且您可以发明自己的键/值对，只要您选择Git今天不使用并且将来不使用的键即可. (如何弄清楚Git在2043年将使用什么，我不知道.:-))主要的例外是某些core.*值，git config 确实有理解，其他几个Git命令可能会自行设置.

There's some fanciness here with keys that are allowed to repeat, vs keys that should only occur once; see the --replace-all and --unset-all options to git config for details. Note that git config itself knows little to nothing about most key and value pairs, and you can invent your own key/value pairs as long as you pick keys that Git is not using today and won't be using in the future. (How you figure out what Git will and won't use in, say, the year 2043, I have no idea. :-) ) The main exceptions are some of the core.* values, which git config does understand, and several other Git commands may set on their own.

(请注意，--unset的处理与替换非常相似.与非all替换一样，它仅取消设置 first 匹配的key = value对.取消设置仅通过不写给定密钥，而不是写替换的key = value.由于git config只是逐行处理文件，因此很容易做到.而且，如果您的key = value是Git完全是全新的，它通过阅读所有行来处理此问题，注意到它没有替换任何现有的key行，因此添加新的key = value行.键是逐节列出的，但是逻辑本身很简单.)

(Note that --unset is handled much the same as replacing. Like a non-all replace, it only unsets the first matching key = value pair. Unsetting is implemented by simply not writing the given key, instead of writing a replacement key = value. Since git config is simply working through the file line-by-line, that's easy to do. Also, if your key = value is totally new, Git handles this by reading through all the lines, noticing that it did not replace any existing key, and hence adding a new key = value line. This is complicated a bit by the fact that the keys are listed section-by-section, but the logic itself is simple enough.)

最后，通读了整个现有配置并完全写出新配置(根据需要使用fflush和fsync和fclose等)，git config调用OS服务以重命名文件，以便将.git/config.lock重命名为.git/config. 在这种情况下，此过程将失败.

Finally, having read through the entire existing configuration and completely written out the new one (using fflush and fsync and fclose and so on as needed), git config invokes the OS service to rename a file, in order to rename .git/config.lock to .git/config. This is where the process is failing in this particular case.

重命名(如果成功)具有将新配置生效 并删除锁定文件的作用，这些操作都是一次原子操作:任何其他Git命令都可以看到完整的旧配置，来自原始的.git/config文件或全新的配置，来自新的.git/config文件，该文件在构造期间称为.git/config.lock.

The rename, if it succeeds, has the effect of putting the new configuration into effect and removing the lock file, all as one atomic operation: any other Git command sees either the complete old configuration, from the original .git/config file, or the complete new configuration, from the new .git/config file that was known during construction as .git/config.lock.

另一个StackOverflow问题问:我们是否能够删除Windows中打开的文件?

Another StackOverflow question asks: Will we ever be able to delete an open file in Windows? The accepted answer includes this statement: An anti virus product that does not open files with full sharing (including deletion) enabled is buggy. If that's the case—that is, if this particular AV software fails to open with the "allow delete" flag, and if such software is buggy, then this particular AV software is the problem and is buggy.

这篇关于Git初始化:致命:无法将'core.filemode'设置为'false'的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！