git lfs中的单文件版本

我试着想清楚你要做些什么才能使这件事成功。有了钩子和过滤器的组合,你至少可以非常接近-但这将是一个很大的工作,我不知道如何使它工作得很好,坦率地说,没有太多的意义。

没什么意义的原因是,LFS 已经 允许您通过修剪不再相关的对象来控制本地LFS存储的大小。的确,如果您签出一个旧的提交(不抑制LFS),您将下载其任何已删除的文件;因此,如果您绝对必须保留文件的最新版本,即使签出历史版本(而不仅仅是愿意容忍这样的行为),或者如果您在2018年度找不到足够的文件存储—即使是中央LFS存储—保留所有版本,您也需要制定其他解决方案。

但如果是这样的话,你需要在LFS之外寻找解决方案。

[1] -如果你想知道更多关于这个声明的细节:LFS使用文件的SHA256散列作为该文件的“文件名”。要说一个文件的两个不同版本不太可能散列到同一个“文件名”是一个巨大的轻描淡写。LFS在git repo中存储的是一个“指针文件”,与git控制下的任何其他文件(a BLOB ),其内容包括LFS对象的“文件名”。因此,在LFS控制下更改文件的内容会更改指针文件的内容。

团块 在git中使用SHA散列命名。尽管这比SHA256的位数少,但仍然不合理地认为任何两个不同的 s将散列到相同的ID(事实上,如果在单个repo中确实发生过这种情况,它将中断git;但是没有理解数学的人会担心。)因此更改LFS中文件的版本将更改repo中指针文件的ID。

从这里开始就差不多了。这个 在 TREE ;所以 s的内容必须更改,以便 树 身份证必须更改。那个 树 可以列为另一个目录下的“子目录” ,如果是这样的话 树 树 对于 COMMIT . 这个 元数据包括 树 提交 身份证必须更改。

一旦 提交 提交 总之。

因此,即使涉及LFS,也确实不可能更改现有提交的内容。您可以创建提交的稍有变化的副本,但将其替换为历史记录是一种重写。