首页 > 解决方案 > 无法将“core.repositoryformatversion”设置为“0”

问题描述

我正在尝试初始化一个新的 git repo。当我git init在目标目录中执行时,我收到以下信息:

error: chmod on /r/test_file_path/.git/config.lock failed: Invalid argument
fatal: could not set 'core.repositoryformatversion' to '0'

我以前从未遇到过这个问题,而且我查找的解决方案似乎很奇怪且脱节。我之前已经在这个目录中初始化了其他 git repos 并且从来没有遇到过问题。任何想法这可能是什么?

标签: gitgithub

解决方案


有一个 2.27 的回归,现在已修复。
但是 v0 存储库中的任何新扩展仍然会被默默地尊重,这是不太正确的。
相反,请使用 Git 2.29(2020 年第四季度)大声抱怨并死去。

请参阅Jeff King ( )提交的 ec91ffc(2020 年 7 月 16 日) 。(由Junio C Hamano 合并 -- --提交 c28a2d0中,2020 年 7 月 30 日)peff
gitster

verify_repository_format(): 抱怨 v0 repo 中的新扩展

签字人:杰夫·金

过去我们犯了一个错误,extensions.*即使存储库格式版本设置为 0。
这很糟糕,因为忘记调整存储库版本意味着旧版本的 Git(它不知道我们的扩展)不会抱怨。
即,这本身不是问题,但这意味着您的存储库处于无法为您提供您认为从旧版本获得的保护的状态。

出于兼容性原因,我们坚持现有扩展的决定。
但是,我们不希望进一步扩大损害。我们可以通过捕获任何新添加的扩展并抱怨存储库格式来做到这一点。

请注意,这是一个非常重的锤子:我们将完全拒绝使用存储库。
一个较小的选择是忽略(可能带有警告)任何新的扩展。但是由于处理扩展的方式,这给添加的每个新扩展带来了负担,以记住“撤消”本身(因为在我们确定是否在 v1 存储库中之前处理它们,因为我们不要坚持配置条目的特定顺序)。

因此,一种选择是重写该处理以在配置解析期间记录任何新的扩展名(及其值),然后只有在我们位于 v1 存储库中时才继续处理新的扩展名。
但我不确定这是否值得麻烦:

  • 无论如何,忽略扩展很可能会导致结果损坏(例如,忽略提议的objectformat扩展意味着解析任何对象数据可能会遇到错误)
  • 这表明编写扩展字段的任何工具都已损坏。我们最好立即有力地通知,这样这些工具甚至不会出现意外工作。

唯一的缺点是修复这种情况有点棘手,因为像 " git config" ( man )这样的程序不想使用存储库。但:

git config --file=.git/config core.repositoryformatversion 1  

应该还是够了。


推荐阅读