Ale*_*ird 16 git version-control configuration repository rcs
我注意到git中的默认选项core.repositoryFormatVersion默认为0,但是什么是"存储库格式版本"以及它们具有哪些功能差异？
hob*_*bbs 28
这对未来的兼容性-如果使用Git的开发永远觉得有必要改变这种回购存储在磁盘上启用一些新功能的方式,那么他们可以升级回购有一个core.repositoryformatversion的1.然后,知道新格式的新版本的git会触发代码来处理它,而没有的旧版本的git会优雅地发生错误"Expected git repo version <= 0, found 1. Please upgrade Git".
截至目前,唯一定义或识别的repo格式版本是0,表示git的每个公开发布使用的格式.
Von*_*onC 12
git 2.7(2015年11月)在新版本中添加了更多信息Documentation/technical/repository-version.txt.
请参阅Jeff King()提交067fbd4,提交00a09d5(2015年6月23日).(由Junio C Hamano合并- -在提交fa46579,2015年10月26日)peff
gitster
您现在可以定义"扩展",并core.repositoryformatversion用作"标记"来表示所述扩展的存在,而不是必须碰撞Git版本号本身:
如果我们要为每个这样的更改碰撞存储库版本,那么任何实现理解版本
X也必须理解X-1,X-2等等,即使不兼容性可能在系统的正交部分,并且没有理由我们不能实现一个没有另一个(或更重要的是,用户不能选择使用一个功能而不另一个,权衡仅针对该特定功能的兼容性).此补丁记录了现有
repositoryformatversion策略并引入了一种新格式"1",它允许存储库指定它必须使用任意一组扩展运行.
来自doc的摘录:
每个git存储库在
core.repositoryformatversion其config文件的键中都标有数字版本 .此版本指定了对磁盘存储库数据进行操作的规则.请注意,这仅适用于直接访问存储库的磁盘内容.只要服务器进程理解格式,
只能理解格式的旧客户端0仍然可以git://使用格式连接到存储库.11版
0这是由git的初始版本定义的格式,包括但不限于存储库目录的格式,存储库配置文件以及对象和ref存储.
版
1此格式与版本相同
0,但以下情况除外:
在读取
core.repositoryformatversion变量时,支持版本1的git实现也必须读取extensions配置文件部分中的任何配置键.如果版本1存储库指定
extensions.*运行的git尚未实现的任何键,则操作不能继续.类似地,如果实现不理解任何已知密钥的值,则操作不能继续.这可以用于,例如:
告知git不应仅根据ref提示的可达性来修剪对象(例如,因为它有"clone --shared"子项)
refs以通常的"refs"和"packed-refs"目录之外的格式存储
现在,这确实是所有发布版本号策略及其semver策略的原始方法.
因为我们碰到格式"1",并且因为格式"1"要求运行的git知道所提到的任何扩展,我们知道旧版本的代码在面对这些新格式时不会做出危险.
例如,如果用户选择将数据库存储用于refs,则可以将"extensions.refbackend"配置设置为"db".
较旧版本的git不会理解格式"1"和保释.
理解"1"但不知道"refbackend"的git版本,或者知道"refbackend"而不是"db"后端的git版本将拒绝运行.
当然,这很烦人,但比声称存储库中没有引用或写入其他实现无法读取的位置的替代方法要好得多.请注意,我们仅在此处定义格式1的规则.
我们自己不会写格式1; 它是一种工具,旨在供用户和未来的扩展使用,以便为旧的实现提供安全性.
作为第一个扩展,你将使用git 2.7 preciousObjects:
如果在存储库中使用此扩展,则不应运行任何可能从对象存储中删除对象的操作.如果您与其他无法看到引用的存储库共享该存储,则此功能非常有用.
该文件提到:
当配置键
extensions.preciousObjects设置true为时,不得删除存储库中的对象(例如,通过git-prune或git repack -d).
那是:
例如,如果你这样做:
$ git clone -s parent child
$ git -C parent config extensions.preciousObjects true
$ git -C parent config core.repositoryformatversion 1
你现在在父存储库中运行git时有额外的安全性.
修剪和git gc重新包装将保留错误,并将跳过这些操作(它将继续打包参考并执行其他非对象操作).
在存储库中运行时,较旧版本的git将在每次操作时失败.请注意,我们不会
preciousObjects在执行"clone -s" 时默认设置扩展名,因为这样做会破坏向后兼容性.这是用户应该明确做出的决定.
请注意,这项core.repositoryformatversion业务已经过时了.真的老了.提交ab9cb76,2005年11月,Git 0.99.9l.
它最初是为db版本完成的:
这使得
init-db存储库版本可识别.它检查现有配置文件是否表示正在重新初始化的存储库是错误的版本,并在进一步损害之前中止.