Git初始化:致命:无法将“core.filemode”设置为“false”

wbgh16ku  于 2023-02-28  发布在  Git
关注(0)|答案(6)|浏览(419)

使用Team City从Git Repo checkout (Gitlabs,如果有必要)
从空的生成目录开始。得到以下错误:
致命错误:无法将"core.filemode"设置为"false"
(在Windows计算机上运行,如果这很重要的话)
团队城市运行的用户被更改为管理员以防万一。
此命令退出时,. git目录不是有效的存储库。
清除整个"work"目录没有帮助。
它随机地来了又去...
与这个:git配置--全局--替换所有核心. fileMode假
没有做任何有用的事情--不管有没有--replace-all,并以管理员或另一个用户的身份运行(如果您将"false"更改为"true",您会得到相同的错误,如果您将其更改为"falseCD",它会将错误更改为无效值--所以很明显,它正在更改它。
有人有什么想法吗?

wljmcqd8

wljmcqd81#

在我的例子中,使用“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.
57hvy0tb

57hvy0tb2#

我不想成为那样的人,但我通过重新启动Windows解决了这个问题。

vohkndzv

vohkndzv3#

Traderhunt游戏将此追溯到一些杀毒软件,这是有道理的,原因与Git用来更新配置条目的进程有关。
git config运行并被告知更改一个或多个配置key = value字段(例如将core.filemode更改为false)时,它实现此操作的方式是使用三步过程:
1.使用创建文件的操作系统服务调用创建一个新的空文件(.git/config.lock),如果文件已存在则失败。如果此步骤失败,则表示另一个git config(或等效)命令 * 已在运行 ,我们必须等待它完成,然后再执行自己的git config
1.读取现有的配置文件,一次读取一个key = value条目。如果键是我们关心的键,则写入 newkey = value值,否则复制现有的key = value
这里有一些花哨的键,允许重复,与键,应该只出现一次;请参阅git config--replace-all--unset-all选项以了解详细信息。注意,git config本身对大多数键和值对几乎一无所知,您可以创建自己的键/值对,只要您选择Git现在不使用,将来也不会使用的键。(我不知道你怎么知道Git在2043年会用什么,不会用什么。:-))主要的例外是一些core.*的值,git config * 不 * 理解这些值,其他几个Git命令可能会自己设置。
(Note --unset的处理方式与replacing非常相似。与非all replace一样,它只会取消设置 * 第一个 * 匹配的key = value对。取消设置只需 * 不写入 * 给定键即可实现,而不是写入替换key = value。由于git config只是逐行处理文件,因此很容易做到。此外,如果你的key = value是全新的,Git会阅读所有的行,注意到它没有替换任何现有的key,因此会 * 添加 * 一个新的key = value行(这有点复杂,因为键是逐段列出的,但逻辑本身足够简单)。
1.最后,在通读了整个现有配置并完全写出新配置(根据需要使用fflushfsyncfclose等)后,git config调用操作系统服务来 * 重命名 * 文件,以便将.git/config.lock重命名为.git/config这就是在此特定情况下流程失败的地方。
如果重命名成功,则会使新配置生效 * 并 * 删除锁定文件,所有这些操作都是一个原子操作:任何其他Git命令要么看到原始.git/config文件中的完整旧配置,要么看到新.git/config文件中的完整新配置,新.git/config文件在构建过程中称为.git/config.lock
另一个StackOverflow问题是:Will we ever be able to delete an open file in Windows?accepted answer包含以下语句:
未启用完全共享(包括删除)打开文件的防病毒产品存在缺陷。* 如果是这种情况,也就是说,如果此特定防病毒软件无法使用“允许删除”标志打开,并且如果此类软件存在缺陷,则此特定防病毒软件存在问题,并且存在缺陷。

mw3dktmi

mw3dktmi4#

当我通过桑巴舞在windows共享驱动器上运行git init挂载到linux时,我遇到了这个错误。我使用sudo进行init,然后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
zwghvu4y

zwghvu4y5#

对我来说,这是一个在**/etc/nsswitch.conf**中注解掉两行的问题
我注解掉的行是:

group: files # db
db_enum: cache builtin

然后关闭并重新打开Cygwin

mqkwyuun

mqkwyuun6#

这个错误出现在Windows WSL中,当我尝试先创建一个newuser,然后从windows树下的文件夹创建git init .时。newuser能够在其linux主目录中创建git仓库。
在WSL中,重新启动Windows并不能解决这个问题。在我的用例中,我需要从Windows命令行发出wsl --shutdown。在此之前,我在WSL linux中创建了/etc/wsl.conf,其内容如下,灵感来自https://stackoverflow.com/a/50856772

[automount]
options = "metadata"

并将newuser加入到Sudo基团中

usermod -aG sudo newuser

当文件夹不属于newuser时,为了不仅能够使用git init .,而且能够使用给定的git仓库,newuser必须运行

git config --global --add safe.directory /mnt/c/...repositorypath

相关问题