Git init: fatal: 无法将 'core.filemode' 设置为 'false'
Git init: fatal: could not set 'core.filemode' to 'false'
使用 Team City 从 Git 回购中签出。 （Git实验室如果重要的话）
从清空构建目录开始。收到此错误：
严重：无法将 'core.filemode' 设置为 'false'
（运行 在 Windows 机器上，如果重要的话）
为了以防万一，Team City 运行正在使用的用户已更改为管理员。
此命令退出时，.Git 目录不是有效的 Repo。
擦除整个 'work' 目录没有帮助。
它随机出现和消失...
还有这个：
git 配置 --global --replace-all core.fileMode false
没有任何用处——有或没有 --replace-all，以及 运行 作为管理员或其他用户（如果您将 'false' 更改为 'true'，您会得到相同的结果错误，如果您将其更改为 'falseCD'，它会将错误更改为无效值 - 很明显，它正在更改它。
有人有什么想法吗？
，这是有道理的。原因与 Git 用于更新配置条目的过程有关。
当git config运行并被告知更改一个或多个配置key = value字段时，例如将core.filemode更改为false，它的实现方式这是使用三步过程：
创建一个新的空文件 (.git/config.lock)，使用创建文件的 OS 服务调用，如果文件已经存在则失败。如果此步骤失败，则表明另一个 git config（或等效）命令 已经 运行 并且我们必须等待它完成才能执行我们自己的 git config.
读取现有配置文件，一次读取一个 key = value 条目。如果key是我们关心的那一个，写new key = value值，否则复制现有的key = value.
允许重复的键与只应出现一次的键之间存在一些异想天开；有关详细信息，请参阅 git config 的 --replace-all 和 --unset-all 选项。请注意，git config 本身对大多数键值对知之甚少，您可以发明自己的 key/value 对，只要您选择 Git 今天未使用且不会使用的键即可。将来不会使用。 （你如何计算出 Git 将在 2043 年使用和不使用什么，我不知道。:-)）主要的例外是一些 core.* 值，其中 git config 明白，其他几个Git命令可以自己设置。
（请注意，--unset 的处理方式与替换非常相似。与非 all 替换一样，它只会取消设置 first 匹配 key = value 对。通过简单地 不写 给定的键，而不是写替换 key = value 来实现取消设置。因为 git config 只是通过文件行工作-逐行，这很容易做到。此外，如果您的 key = value 是全新的，Git 通过阅读所有行来处理此问题，注意它没有替换任何现有的 key , 因此 添加 一个新的 key = value 行。这有点复杂，因为键是逐节列出的，但逻辑本身很简单。 )
最后，通读整个现有配置并完全写出新配置（根据需要使用 fflush 和 fsync 和 fclose 等), git config 调用 OS 服务来 重命名 文件，以便将 .git/config.lock 重命名为 .git/config。 在这种特殊情况下，这是进程失败的地方。
重命名，如果成功，会使新配置生效和删除锁定文件，所有这些都是一个原子操作：任何其他Git 命令可以从原始 .git/config 文件中查看完整的旧配置，或者从新的 .git/config 文件中查看完整的新配置，该文件在构建期间被称为 .git/config.lock.
另一个 Whosebug 问题询问：Will we ever be able to delete an open file in Windows? The accepted answer 包含此声明：不打开启用了完全共享（包括删除）的文件的反病毒产品是错误的。 如果就是这种情况——也就是说，如果这个特定的 AV 软件无法使用 "allow delete" 标志打开，并且如果此类软件有错误，那么这个特定的 AV 软件就是问题所在并且有错误。
就我而言，使用 "sudo" 对我有用。例如：
asif@asif-vm:/mnt/prog/protobuf_tut$ git clone https://github.com/protocolbuffers/protobuf.git
Cloning into 'protobuf'...
error: chmod on /mnt/prog/protobuf_tut/protobuf/.git/config.lock failed: Operation not permitted
fatal: could not set 'core.filemode' to 'false'
完成 "sudo" 后我可以让它工作：
asif@asif-vm:/mnt/prog/protobuf_tut$ sudo git clone https://github.com/protocolbuffers/protobuf.git
Cloning into 'protobuf'...
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 66782 (delta 0), reused 0 (delta 0), pack-reused 66777
Receiving objects: 100% (66782/66782), 55.83 MiB | 2.04 MiB/s, done.
Resolving deltas: 100% (45472/45472), done.
Checking out files: 100% (2221/2221), done.
我讨厌成为那个人，但我通过重新启动 Windows 解决了这个问题。
对我来说，这是在 /etc/nsswitch.conf
中注释掉两行的问题
我注释掉的行是：
group: files # db
db_enum: cache builtin
然后关闭并重新打开 cygwin
当 运行 git init 上的 windows 共享驱动器通过 samba 安装到 linux 时，我遇到了这个错误。我使用 sudo 进行初始化，然后 chown 回到原始用户，从那以后一切都很好：
sudo git init # no error
sudo chown user:user .git -R # drop sudo requirement
git add file1 # works normally
git commit -am bla # works normally
使用 Team City 从 Git 回购中签出。 （Git实验室如果重要的话）
从清空构建目录开始。收到此错误：
严重：无法将 'core.filemode' 设置为 'false'
（运行 在 Windows 机器上，如果重要的话）
为了以防万一，Team City 运行正在使用的用户已更改为管理员。
此命令退出时，.Git 目录不是有效的 Repo。
擦除整个 'work' 目录没有帮助。
它随机出现和消失...
还有这个： git 配置 --global --replace-all core.fileMode false
没有任何用处——有或没有 --replace-all，以及 运行 作为管理员或其他用户（如果您将 'false' 更改为 'true'，您会得到相同的结果错误，如果您将其更改为 'falseCD'，它会将错误更改为无效值 - 很明显，它正在更改它。
有人有什么想法吗？
当git config运行并被告知更改一个或多个配置key = value字段时，例如将core.filemode更改为false，它的实现方式这是使用三步过程：
创建一个新的空文件 (
.git/config.lock)，使用创建文件的 OS 服务调用，如果文件已经存在则失败。如果此步骤失败，则表明另一个git config（或等效）命令 已经 运行 并且我们必须等待它完成才能执行我们自己的git config.读取现有配置文件，一次读取一个
key = value条目。如果key是我们关心的那一个，写newkey = value值，否则复制现有的key = value.允许重复的键与只应出现一次的键之间存在一些异想天开；有关详细信息，请参阅
git config的--replace-all和--unset-all选项。请注意，git config本身对大多数键值对知之甚少，您可以发明自己的 key/value 对，只要您选择 Git 今天未使用且不会使用的键即可。将来不会使用。 （你如何计算出 Git 将在 2043 年使用和不使用什么，我不知道。:-)）主要的例外是一些core.*值，其中git config明白，其他几个Git命令可以自己设置。（请注意，
--unset的处理方式与替换非常相似。与非all替换一样，它只会取消设置 first 匹配key = value对。通过简单地 不写 给定的键，而不是写替换key = value来实现取消设置。因为git config只是通过文件行工作-逐行，这很容易做到。此外，如果您的key = value是全新的，Git 通过阅读所有行来处理此问题，注意它没有替换任何现有的key, 因此 添加 一个新的key = value行。这有点复杂，因为键是逐节列出的，但逻辑本身很简单。 )最后，通读整个现有配置并完全写出新配置（根据需要使用
fflush和fsync和fclose等),git config调用 OS 服务来 重命名 文件，以便将.git/config.lock重命名为.git/config。 在这种特殊情况下，这是进程失败的地方。
重命名，如果成功，会使新配置生效和删除锁定文件，所有这些都是一个原子操作：任何其他Git 命令可以从原始 .git/config 文件中查看完整的旧配置，或者从新的 .git/config 文件中查看完整的新配置，该文件在构建期间被称为 .git/config.lock.
另一个 Whosebug 问题询问：Will we ever be able to delete an open file in Windows? The accepted answer 包含此声明：不打开启用了完全共享（包括删除）的文件的反病毒产品是错误的。 如果就是这种情况——也就是说，如果这个特定的 AV 软件无法使用 "allow delete" 标志打开，并且如果此类软件有错误，那么这个特定的 AV 软件就是问题所在并且有错误。
就我而言，使用 "sudo" 对我有用。例如：
asif@asif-vm:/mnt/prog/protobuf_tut$ git clone https://github.com/protocolbuffers/protobuf.git
Cloning into 'protobuf'...
error: chmod on /mnt/prog/protobuf_tut/protobuf/.git/config.lock failed: Operation not permitted
fatal: could not set 'core.filemode' to 'false'
完成 "sudo" 后我可以让它工作：
asif@asif-vm:/mnt/prog/protobuf_tut$ sudo git clone https://github.com/protocolbuffers/protobuf.git
Cloning into 'protobuf'...
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 66782 (delta 0), reused 0 (delta 0), pack-reused 66777
Receiving objects: 100% (66782/66782), 55.83 MiB | 2.04 MiB/s, done.
Resolving deltas: 100% (45472/45472), done.
Checking out files: 100% (2221/2221), done.
我讨厌成为那个人，但我通过重新启动 Windows 解决了这个问题。
对我来说，这是在 /etc/nsswitch.conf
中注释掉两行的问题我注释掉的行是：
group: files # db
db_enum: cache builtin
然后关闭并重新打开 cygwin
当 运行 git init 上的 windows 共享驱动器通过 samba 安装到 linux 时，我遇到了这个错误。我使用 sudo 进行初始化，然后 chown 回到原始用户，从那以后一切都很好：
sudo git init # no error
sudo chown user:user .git -R # drop sudo requirement
git add file1 # works normally
git commit -am bla # works normally