Git的想象力

最近因为发现git gc --prune能省不少空间,于是就想起去翻翻git的文档.

虽然用git也算有几年了,但多数还是当作一种version control的东西来用.
看了之后才发觉,这个不单跟传统的version control有很大区别,甚至跟version control本身也有相当程度的不同.

官方文档给出的直观解释是git本身是一个类似的snapshot的管理工具.
跟version control不同,它目的似乎不是为了存储变更记录,而是存储变更本身.

换句话说,version control做的事情的专注点在于replay changeset.
而git的侧重点似乎在于各个snapshot之间的traversal了.

虽然看上去好像是差不多的事情,但是对个人来说,还是挺大的一个观念转变的.

以每一个单独的文件为视角的话,其实就是一个类似state transfer的graph,不同的branch以及sub tree就是不同的edge set.

考虑到每个transfer都是一个文件hash为基础的,那么就存在一些merge或者rebase,使得这个文件的history graph不是一个单纯的树.
而是存在一些环壮结构.
因为可能后面的改动会使得文件跟之前的某个"版本"一致.

从repo的角度看的话,就是一个文件代表着一个这样的graph.
而repo角度的change set则是这个repo下面的某些文件集合的change set构成的.

也就是说,对于这个repo的某个"version"来说,相当于在这些文件的graph之间,以这个version标记的change set产生了联系.
也就是直观上的,把每个文件的graph以version的维度连接了起来.

因为repo本身有多个version.
所以,这些被连接起来的graph,在不同的version层次又有着不同的连接.

也就是说,原来的一个graph forest变成了一个hyper graph.

如果再以类似github这种地方,把各个repo的hyper graph以文件为基准连接起来的话,就是一个更复杂的hyper graph了.

这个隐含的假设是,不同的项目之间,存在着相同的文件/实现.
通过这些共同点,就有可能把各个repo连接起来.

这样的话,就存在一个联通的hyper graph,使得这个hyper graph实际上是有多个repo的history构成的.

那么,这样的hyper graph有什么用的?

至少可以用来做一些简单统计吧.
比如公用了某个库或者文件的项目有哪些,或者某个repo的链入/热度/受欢迎程度如何.

实际一点的,可能是解决project的版本冲突问题.
比如,根据当前的版本,就可以"横向"地从其他repo里根据公有文件的version,cut出一个aspect来,使得所有文件都是处于同一个版本时间线上的.
而在即使这样都不能解决版本冲突的情况下,至少还能对冲突的部分做出具体的冲突比较,看是不是可以兼容的.

事实上,这就类似于page之间的link.
本质就是一些hyper graph.

至于要用来rank还是拿来干其他什么.

剩下的就是想象力的问题了.