git 中有哪些不同的存储库格式版本（对于 core.repositoryFormatVersion 设置）？

Question

我注意到 git core.repositoryFormatVersion 中的默认选项默认为 0，但是什么是“存储库格式版本”以及它们有何功能差异？

Answer 1

这是为了未来的兼容性——如果 git 开发人员发现有必要更改存储库在磁盘上存储的方式以启用某些新功能，那么他们可以使升级后的存储库的 core.repositoryformatversion 为 <代码>1。然后，知道该新格式的较新版本的 git 将触发代码来处理它，而不知道该新格式的较旧版本的 git 将优雅地错误 “预期 git 存储库版本 <= 0，发现 1。请升级 Git”。

截至目前，定义或识别的唯一存储库格式版本是 0，它表示 git 的每个公开版本都使用的格式。

Answer 2

git 2.7（2015 年 11 月）在新的 文档/技术/repository-version.txt。
请参阅 提交 067fbd4、提交 00a09d5 （2015 年 6 月 23 日）作者：Jeff King （peff）。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 fa46579，2015 年 10 月 26 日）}

现在，您可以定义“扩展”，并且使用 core.repositoryformatversion 作为“标记”来表明所述扩展的存在，而不必更改 Git 版本号本身：

如果我们要为每个此类更改提高存储库版本，那么任何理解版本 X 的实现也必须理解 X-1、X- 2 等等，即使不兼容可能出现在系统的正交部分，而且我们没有理由不能
实现一个功能而不使用另一个功能（或者更重要的是，用户不能选择使用一个功能而不使用另一个功能，仅权衡该特定功能的兼容性）。

此补丁记录了现有的repositoryformatversion策略，并引入了一种新格式“1”，它允许存储库指定它必须与任意一组扩展一起运行。

文档摘录：

每个 git 存储库都在目录中标有数字版本
其 config 文件的 core.repositoryformatversion 键。这个版本
指定对磁盘存储库数据进行操作的规则。

请注意，这仅适用于访问存储库的磁盘内容
直接。
仅理解格式 0 的旧客户端仍可以通过 git:// 连接到使用格式 1 的存储库，只要服务器进程理解格式1。

版本0

这是git初始版本定义的格式，包括但不限于存储库目录、存储库配置文件以及对象和引用存储的格式。

版本1

此格式与版本 0 相同，但有以下例外：

1. 读取core.repositoryformatversion变量时，git
   支持版本 1 的实现也必须读取任何
   配置键可以在extensions部分找到
   配置文件。

2. 如果版本 1 存储库指定了任何 extensions.* 键，
   正在运行的 git 尚未实现，该操作不得
   继续。
   同样，如果任何已知键的值不被理解
   通过实现，操作不得继续。

这可以使用，例如：

• 通知 git 不应基于对象进行修剪
  仅取决于参考提示的可达性（例如，因为它
  有“clone --shared”子项）

• 参考文献以不同于通常格式的格式存储
  “refs”和“packed-refs”目录

现在，这确实是所有发布版本号策略及其的原始方法semver 政策。

因为我们遇到格式“1”，并且因为格式“1”要求正在运行的 git 了解所提到的任何扩展，所以我们知道旧版本的代码在面对这些新格式时不会做出危险的事情。< /p>

例如，如果用户选择使用数据库存储来存储引用，他们可以将“extensions.refbackend”配置设置为“db”。
旧版本的 git 无法理解格式“1”和 bail。
理解“1”但不知道“refbackend”的 git 版本，或者知道“refbackend”但不知道“db”后端的 git 版本将拒绝运行。
当然，这很烦人，但比声明存储库中没有引用或写入其他实现无法读取的位置的替代方案要好得多。

请注意，我们在此仅定义格式 1 的规则。
我们自己从来不写格式 1； 它是一个供用户和未来扩展使用的工具，旨在为旧实现提供安全性。

---

作为第一个扩展，您将拥有 git 2.7 preciousObjects：

如果在存储库中使用此扩展，则不应运行可能从对象存储中删除对象的操作。如果您与其他您看不到其引用的存储库共享该存储，这可能会很有用。

该文档提到：

当配置键extensions.preciousObjects设置为true时，存储库中的对象不得被删除（例如，通过git-prune 或git repack -d）。




那是：

例如，如果您这样做：

$ git clone -s 父子
$ git -C 父配置扩展.preciousObjects true
$ git -C 父配置 core.repositoryformatversion 1

现在，在父存储库中运行 git 时，您可以更加安全。
修剪和重新打包将出现错误，并且 git gc 将跳过这些操作（它将继续打包引用并执行其他非对象操作）。
旧版本的 Git 在存储库中运行时，每次操作都会失败。

请注意，在执行“clone -s”时，默认情况下我们不会设置 preciousObjects 扩展名，因为这样做会破坏向后兼容性。这是用户应该明确做出的决定。

---

请注意，此 core.repositoryformatversion 业务已经过时了。真的老了。 提交 ab9cb76，2005 年 11 月，Git 0.99.9l。
最初是针对数据库版本完成的：

这使得 init-db 存储库版本感知。

它会检查现有配置文件是否表明正在重新初始化的存储库版本错误，并在造成进一步损害之前中止。

---

Git 2.22（2019 年第二季度）将避免周围的泄漏
repository_format 结构。

请参阅提交 e8805af（2019 年 2 月 28 日）和 提交 1301997（2019 年 1 月 22 日），作者：马丁·奥格伦 (``)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 6b5688b，2019 年 3 月 20 日）}

setup：使用structrepository_format修复内存泄漏

在我们设置了structrepository_format之后，它拥有各个部分
分配的内存。然后我们要么使用这些成员，因为我们决定我们
想要使用“候选”存储库格式，或者我们放弃
候选/暂存空间。
在第一种情况下，我们将内存的所有权转移给一些全局变量。在后一种情况下，我们只是默默地删除该结构并最终导致内存泄漏。

引入一个初始化宏REPOSITORY_FORMAT_INIT和一个
函数 clear_repository_format()，在每一侧使用
read_repository_format()。要有清晰简单的内存归属，
让 structrepository_format 的所有用户复制以下字符串：
他们从中获取，而不是窃取指针。

在 read_...() 开始时调用 clear_...() 而不是仅仅归零
结构体，因为我们有时会多次输入该函数。
因此，在调用 read_...() 之前初始化结构体非常重要，因此
记录下来。
这也很重要，因为在调用 clear_...() 之前我们甚至可能不会调用 read_...()，例如，参见 builtin/init- db.c.

教导read_...()在错误时清除结构，以便将其重置为
安全状态，并记录下来。 （在setup_git_directory_gently()中，我们
看看repo_fmt.hash_algo，即使repo_fmt.version是-1，我们
实际上不应该按照 API 执行此操作。这次提交之后，那就是
好的。）

---

使用 Git 2.28（2020 年第 3 季度），运行时本身可以自动升级存储库格式版本，例如在非浅层提取时。

请参阅 提交 14c7fa2、提交 98564d8, 提交01bbbbd，提交 16af5f1（2020 年 6 月 5 日），作者：李鑫 (livid)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 1033b98，2020 年 6 月 29 日）}

fetch：允许在初始后添加过滤器克隆

^{签字人：李鑫}

追溯添加过滤器对于现有浅克隆非常有用，因为它们允许用户查看早期的更改历史记录，而无需在常规 --unshallow 提取中下载所有 git 对象。

如果没有此补丁，用户可以通过编辑存储库配置来进行部分克隆，将远程版本转换为承诺者，例如：

git config core.repositoryFormatVersion 1
git config extensions.partialClone 原点 
git fetch --unshallow --filter=blob:无来源

由于完成这项工作的困难部分已经就位，并且此类编辑可能容易出错，因此请教 Git 自动执行所需的配置更改。

请注意，此更改不会修改现有的 Git 行为，该行为可在不更改 repositoryFormatVersion 的情况下识别设置 extensions.partialClone。

---

警告：在 2.28-rc0 中，我们纠正了一个错误，即即使在版本 0 存储库中，某些存储库扩展也会被错误地接受（extensions.* 命名空间中的这些配置变量应该在其存储库中具有特殊含义）版本号为 1 或更高），但这个变化有点太大了。

请参阅 提交 62f2eca、提交 1166419（2020 年 7 月 15 日），作者：Jonathan Nieder （artagnon）。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 d13b7f2，2020 年 7 月 16 日）}

还原“check_repository_format_gently()：拒绝扩展对于旧存储库”

^{报告人：Johannes Schindelin
签字人：Jonathan Nieder}

这将恢复提交 14c7fa269e42df4133edd9ae7763b678ed6594cd。

ab9cb76f661core.repositoryFormatVersion 字段> ("仓库格式版本检查。", 2005-11-25, Git v0.99.9l -- merge），由于 Martin Atukunda 的一些受欢迎的分析，提供了一些受欢迎的前向兼容性。

语义很简单：将 core.repositoryFormatVersion 设置为 0 的存储库应该可以被所有正在使用的 Git 实现所理解； Git 实现应该尽早出错，而不是尝试对具有较高 core.repositoryFormatVersion 值（表示它们不理解的新格式）的 Git 存储库进行操作。

直到00a09d57eb8（引入“扩展”形式的 core.repositoryformatversion，2015-06-23）。

这为 Git 存储库提供了更细粒度的扩展机制。

在 core.repositoryFormatVersion 设置为 1 的存储库中，Git 实现可以作用于“extensions.*”设置，从而修改存储库的解释方式。

在存储库格式版本 1 中，无法识别的扩展设置会导致 Git 出错。

如果用户设置扩展设置但忘记将存储库格式版本增加到 1，会发生什么？
在这种情况下，扩展设置仍然可以被识别；更糟糕的是，无法识别的扩展设置不会导致 Git 出错。

因此，将存储库格式版本 0 与扩展设置相结合，在某种意义上会产生两全其美的结果。

为了改善这种情况，自 14c7fa269e4 (check_repository_format_gently()< /code>: 拒绝旧存储库的扩展，2020-06-05）Git 相反会忽略 v0 模式下的扩展。这样，v0 存储库即可获取历史（2015 年之前）行​​为，并保持与不了解 v1 格式的 Git 实现的兼容性。

不幸的是，用户一直在使用这种配置，这种行为变化让许多人感到惊讶：

• 按照建议启用extensions.worktreeConfig（无需增加存储库格式版本）的“git config --worktree”用户将找到他们的工作树配置不再生效
• 已设置 extensions.partialClone 等工具，例如 copybara code> 在现有存储库中（同时不增加存储库格式版本）会发现设置不再生效




如果我们回去的话，14c7fa269e4中引入的行为可能是一个很好的行为到了 2015 年，但我们已经太晚了。

出于某种原因，我认为这是最初实现的内容，但它已经倒退了。

抱歉，在 14c7fa269e4 正在开发时没有进行研究。

让我们回到 2015 年以来的行为：始终对 extensions.* 设置进行操作，无论存储库格式版本如何。

当我们在这里时，包括一些测试来描述对“升级存储库版本”代码路径的影响。